另外可参考以下文件:
http://pan.baidu.com/s/1kTJscWR
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, calledthreadedinterrupt 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 hasposted 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 abottom 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 newrequest_irq().
The quick_check_handler checks to see if the interrupt was fromthe device, returningIRQ_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 ofIRQ_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 thestruct irqaction. In addition, apointer to the
struct irqaction has been added to thetask_struct so that handlers can check theaction 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 aconcern 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 thelinux-next treewould be a logical next step, possibly followed by mainline merging for 2.6.29.