kernel-rt handling of hardware interrupts

Solution In Progress - Updated -


  • How are hardware interrupts handled in kernel-rt? Documentation states: "MRG Realtime modifies the way interrupts are handled in order to improve performance, and decrease latency."


On the RHEL6 kernel, as well the default behaviour on vanilla kernel (non RT), when an interrupt is activated it starts to run (unless the interrupts are explicitly disabled, or executing another IRQ handler), stopping the current process on the processor that will run the interrupt handler. So, in this setup, we can assume that the interrupt handlers always have a higher priority than any process.

On the kernel-rt (MRG RT kernel), as well on kernel >= 2.6.39 (IIRC) with threadirqs kernel parameter, the IRQ handler's code run as kernel threads. This means that, when an interrupt is activated it does not run the interrupt handler code, it just wakes up the thread that will run the interrupt handler code. Thus, the interrupt handlers can be prioritized as a process in such way that is possible to have an user process with a higher priority than a interrupt handler of a "low priority" device.

Another point is: When kernel is handling an IRQ, it disables the interrupts on current processor, delaying the deliver of another IRQ until the kernel returns from the current IRQ handler's execution. It means that on vanilla kernel, a IRQ of a "high priority device" can be delayed by the amount of time to execute the code of a "low priority"device. On the other hand, as the IRQ handlers on kernel-rt just wake up the thread that will run the devices's handler code, the kernel keeps the interrupt disabled by a short period, giving a fast response time for the delayed IRQ. As the threads of these two IRQ can be configured with different priorities, even if a high priority IRQ came after a low priority IRQ, the IRQ handler thread with a higher priority will run before the other IRQ handler, due to its higher priority on the scheduler.

Although the vanilla kernel >= 2.6.39 can run the IRQs as thread, it does not bring a lot of another benefits from the kernel-rt. The kernel-rt disables the IRQs less often, and for shorter periods than the vanilla kernel does, giving fast responses for the IRQ handlers.

So, on the kernel-rt the IRQ handlers can be configured in a more predictable way, giving a better response time with less jitter for high priority process, being the process an IRQ handler, or user process.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.