Turning Linux into a real-time operating system consisted - simply spoken - of determining sources of latencies and removing them. One important source of latencies are drivers and specifically their interrupt service routine (ISR). In consequence, a mechanism had to be invented to enable scheduling during ISR execution. This may not be terribly efficient at the top of the ISR where hardware is accessed frequently, e.g. to acknowledge the interrupt and to access the various data and status registers of a particular controller. But it may be very effective at the bottom of the ISR where hardware is accessed less frequently. This feature - called "threaded interrupts" - was always part of the PREEMPT_RT patches (see real-time road map), but did not make it into the mainline kernel yet - until now when the required infrastructure was merged into the release candidate of Linux 2.6.30. Thomas Gleixner, the main author behind the threaded interrupts patch, mentioned several advantages of threaded interrupts in his posting "Add support for threaded interrupt handlers - V3". Some of them apply to the normal non-realtime kernel as well. Among others, threaded interrupts will
- allow to move long running handlers out of the hard interrupt context,
- avoid complex hardirq -> tasklet/softirq interaction and locking problems by integrating this functionality into the threaded handler code,
- improve debugging of the kernel: faulty handlers no longer take down the entire system,
- allow prioritizing handlers which share a single interrupt line, and
- have the potential to improve the I/O performance by decoupling the various parts of the ISR from each other
In fact, first tests of drivers that have been converted to threaded interrupts have shown considerable performance gains.
Linux subsystem maintainers will use the remaining two months of the 2.6.30 gestation period to implement threaded interrupt support. If all works well, this feature will then be fully available in the unpatched 2.6.31 kernel. Jonathan, we are coming.
- allow to move long running handlers out of the hard interrupt context,
- avoid complex hardirq -> tasklet/softirq interaction and locking problems by integrating this functionality into the threaded handler code,
- improve debugging of the kernel: faulty handlers no longer take down the entire system,
- allow prioritizing handlers which share a single interrupt line, and
- have the potential to improve the I/O performance by decoupling the various parts of the ISR from each other
In fact, first tests of drivers that have been converted to threaded interrupts have shown considerable performance gains.
Linux subsystem maintainers will use the remaining two months of the 2.6.30 gestation period to implement threaded interrupt support. If all works well, this feature will then be fully available in the unpatched 2.6.31 kernel. Jonathan, we are coming.
