Predictable Interrupt Management for Real Time Kernels over conventional PC Hardware

Leyva-del-Foyo, Luis Eduardo; Mejía-Álvarez, Pedro; Niz, Dionisio de

doi:10.1109/rtas.2006.34

Cited by 49 publications

(54 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This can lead to a priority inversion problem, in which semantically LP interrupt handling can block the execution of a HP process. Towards addressing this problem in a real-time context, a couple of studies [1,6] propose the integration of interrupt handling and process scheduling into a single priority space, but in opposite ways. One approach [1] describes a mechanism to treat interrupt handlers as threads, and the other one [6] introduces a platform that manages threads through interrupt handling.…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Priority-Based Network Interrupt Scheduling for Predictable Real-Time Support

Lee¹,

Kim²,

Shin³

2015

Journal of Computing Science and Engineering

View full text Add to dashboard Cite

Interrupt handling is generally separated from process scheduling. This can lead to a scheduling anomaly and priority inversion. The processor can interrupt a higher priority process that is currently executing, in order to handle a network packet reception interruption on behalf of its intended lower priority receiver process. We propose a new network interrupt handling scheme that combines interrupt handling with process scheduling and the priority of the process. The proposed scheme employs techniques to identify the intended receiver process of an incoming packet at an earlier phase. We implement a prototype system of the proposed scheme on Linux 2.6, and our experiment results show that the prototype system supports the predictable real-time behavior of higher priority processes even when excessive traffic is sent to lower priority processes.

show abstract

Section: Related Workmentioning

confidence: 99%

“…This can lead to priority inversion [1]. As an example, let us consider a network interface card (NIC) signaling an interrupt to notify an incoming network packet.…”

Section: Introductionmentioning

confidence: 99%

Priority-Based Network Interrupt Scheduling for Predictable Real-Time Support

Lee¹,

Kim²,

Shin³

2015

Journal of Computing Science and Engineering

View full text Add to dashboard Cite

show abstract

“…The high-priority task is interrupted by the timer interrupt, whose handler then checks which task is to be activated, and inserts this low-priority task into the ready queue. Thus, code is executed on behalf of a low-priority task while a high-priority task is running or ready to run; Leyva del Foyo et al coined the term rate-monotonic priority inversion for that phenomenon [5]. The priority inversion interruptions exhibited by the commercial AUTOSAR OS kernel are really heavy-weight: The corresponding handlers execute for 2,075 clock cycles each.…”

Section: ) Avoiding Unnecessary Irqsmentioning

confidence: 99%

Sloth on Time: Efficient Hardware-Based Scheduling for Time-Triggered RTOS

Hofer

Danner

Müller

et al. 2012

2012 IEEE 33rd Real-Time Systems Symposium

View full text Add to dashboard Cite

Abstract-Traditional time-triggered operating systems are implemented by multiplexing a single hardware timer-the system timer-in software, having the kernel maintain dispatcher tables at run time. Our SLOTH ON TIME approach proposes to make use of multiple timer cells as available on modern microcontroller platforms to encapsulate dispatcher tables in the timer configuration, yielding low scheduling and dispatching latencies at run time. SLOTH ON TIME instruments available timer cells in different roles to implement time-triggered task activation, deadline monitoring, and time synchronization, amongst others.By comparing the SLOTH ON TIME kernel implementation to two commercial kernels, we show that our concept significantly reduces the overhead of time-triggered operating systems. The speed-ups in task dispatching that it achieves range up to a factor of 171 x, and its dispatch latencies go as low as 14 clock cycles. Additionally, we demonstrate that SLOTH ON TIME minimizes jitter and increases schedulability for its real-time applications, and that it avoids situations of priority inversion where traditional kernels fail by design. I. INTRODUCTION AND MOTIVATIONIn operating system engineering, the overhead induced by the kernel is a crucial property since operating system kernels do not provide a business value of their own. This is especially true in embedded real-time systems, where superfluous bytes in RAM and ROM as well as unnecessary event latencies can decide whether a kernel is used for the implementation of an embedded device or not. In previous work on the SLOTH approach, we have shown that by using commodity microcontroller hardware in a more sophisticated manner in the kernel, we can achieve lower footprints in RAM and ROM as well as very low system call overheads [7]. To achieve this, the SLOTH kernel maps run-to-completion tasks to interrupt handlers and lets the interrupt hardware schedule them, eliminating the need for a software task scheduler completely. Additionally, we have been able to show that implementing a full thread abstraction with blocking functionality in the SLEEPY SLOTH kernel still yields a significant performance boost over traditional, software-based embedded kernels [8].However, both the SLOTH and the SLEEPY SLOTH kernels target event-triggered real-time systems with event-driven task dispatching. In this paper, we discuss how the SLOTH principle of making better use of hardware facilities in the implementation of embedded kernels can be applied to timetriggered operating systems. The resulting SLOTH ON TIME kernel uses the fundamental task dispatching mechanisms as

show abstract

“…While others have proposed methods to unify task and interrupt scheduling [10], or have considered bandwidth constraints on device driver execution [9], Quest attempts to combine both the prioritization of I/O events and budget limits for their handling with task scheduling. In doing so, we describe a method to integrate asynchronous event processing for both device interrupts and tasks waking up after the completion of blocking (e.g., I/O) operations.…”

Section: Related Workmentioning

confidence: 99%