Moving interrupts to threads
Moving interrupts to threads
Processing interrupts from the hardware is a major source of latency in thekernel, because other interrupts are blocked while doing that processing.For this reason, the realtime tree has a feature, called threadedinterrupt handlers, that seeks to reduce the time spent with interruptsdisabled to a bare minimum—pushing the rest of the processing outinto kernel threads. But it is not just realtime kernels that areinterested in lower latencies, so threaded handlers are being proposed foraddition to the mainline.
Reducing latency in the kernel is one of the benefits, but there are otheradvantages as well. The biggest is probably reducing complexity by simplifying or avoiding locking between the "hard"and "soft" parts of interrupt handling. Threaded handlers will also help thedebuggability of the kernel and may eventually lead to the removal of tasklets from Linux. Forthese reasons, and a few others as well, Thomas Gleixner has posted a set of patches and a"request for comments" to add threaded interrupt handlers.
Traditionally, interrupt handling has been done with top half(i.e. the "hard" irq) that actually responds to the hardware interrupt and a bottom half (or"soft" irq) that is scheduled by the top half to do additional processing. The top halfexecutes with interrupts disabled, so it is imperative that it do as littleas possible to keep the system responsive. Threadedinterrupt handlers reduce that work evenfurther, so the top half would consist of a "quick check handler" that justensures the interrupt is from the device; if so, it simply acknowledges theinterrupt to the hardware and tells the kernel to wake the interrupt handler thread.
In the realtime tree, nearly all drivers were mass converted to usethreads, but the patch Gleixner proposes makes it optional—drivermaintainers can switch if they wish to. Automatically converting driversis not necessarily popular with all maintainers, but it has an additionaldownside as Gleixner notes: "Converting an interrupt to threadedmakes only sense when the handler code takes advantage of it by integrating tasklet/softirqfunctionality and simplifying the locking."
A driver that wishes to request a threaded interrupt handler will use:
int request_threaded_irq(unsigned int irq, irq_handler_t handler, irq_handler_t quick_check_handler, unsigned long flags, const char *name, void *dev)This is essentially the same as request_irq() with the addition ofthe quick_check_handler. As requested by Linus Torvalds atthis year's Kernel Summit, a new function was introduced rather thanchanging countless drivers to use a new request_irq().
The quick_check_handler checks to see if the interrupt was fromthe device, returning IRQ_NONE if it isn't. It can also returnIRQ_HANDLED if no further processing is required orIRQ_WAKE_THREAD to wake the handler thread. One other return codewas added to simplify converting to a threaded handler. Aquick_check_handler can be developed prior to the handler being converted; in that case, it returnsIRQ_NEEDS_HANDLING (instead of IRQ_WAKE_THREAD) whichwill call the handler in the usual way.
request_threaded_irq() will create a thread for the interrupt andput a pointer to it in the struct irqaction. In addition, apointer to the struct irqaction has been added to thetask_struct so that handlers can check the action flagsfor newly arrived interrupts. That reference is also used to preventthread crashes from causing an oops. Oneof the few complaints seen so far about the proposal was a concern about wasting four or eight bytes in eachtask_struct that was not an interrupt handler (i.e. the vastmajority). That structure could be split into two types, one for thekernel and one for user space, but it is unclear whether that will be necessary.
Andi Kleen has a more general concern that threaded interrupt handlers willlead to bad code: "to be honest my opinion is that it will encourage badly written interrupt code longer term," but he seems to be in the minority. There wererelatively few comments, but most seemed in favor—perhaps many arewaiting to see the converted driver as Gleixner promises to deliver "realsoon". If major obstacles don't materialize, one would guess the linux-next treewould be a logical next step, possibly followed by mainline merging for 2.6.29.