# LWN 302043: 中断线程化

Processing interrupts from the hardware is a major source of latency in the kernel, because other interrupts are blocked while doing that processing. For this reason, the realtime tree has a feature, called

, that seeks to reduce the time spent with interrupts disabled to a bare minimum—pushing the rest of the processing out into kernel threads. But it is not just realtime kernels that are interested in lower latencies, so threaded handlers are being proposed for addition to the mainline.

” 的功能，该功能试图将内核在关中断状态下需要执行的工作量压缩到最低限度，同时将其余的中断处理全部安排到一个内核线程中去完成。不是只有实时内核才会对低延迟感兴趣，同样地，有人建议将 “中断线程化” 这个特性也添加到内核主线中去。

Reducing latency in the kernel is one of the benefits, but there are other advantages 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 the debuggability of the kernel and may eventually lead to the removal of tasklets
from Linux. For these reasons, and a few others as well, Thomas Gleixner has posted

。出于以上原因，也由于其他的一些原因，Thomas Gleixner 提交了

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 half executes with interrupts disabled, so it is imperative that it do as little as possible to keep the system responsive. Threaded interrupt handlers reduce that work even further, so the top half would consist of a “quick check handler” that just ensures the interrupt is from the device; if so, it simply acknowledges the interrupt to the hardware and tells the kernel to wake the interrupt handler thread.

”（也被称为 “hard” irq）负责实际的对硬件中断的响应处理，“

”（或称之为 “soft” irq）由 “上半部” 负责调度并执行额外的处理。“上半部” 在禁用中断的情况下执行，因此必须尽可能地快，从而不会给系统响应造成太大的延迟。中断线程化后进一步压缩了这部分的工作量，“上半部” 的工作仅仅需要完成 “快速检查”，譬如确保中断的确来自期望的设备；如果检查通过，它将对硬件中断完成确认并通知内核唤醒中断处理线程完成中断处理的 “下半部”。

In the realtime tree, nearly all drivers were mass converted to use threads, but the patch Gleixner proposes makes it optional—driver maintainers can switch if they wish to. Automatically converting drivers is not necessarily popular with all maintainers, but it has an additional downside as Gleixner notes: “ Converting an interrupt to threaded makes only sense when the handler code takes advantage of it by integrating tasklet/softirq functionality 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 of the quick_check_handler
. As requested by Linus Torvalds
at this year’s Kernel Summit, a new function was introduced rather than changing countless drivers to use a new request_irq()
.

，这里采用的方式是引入了一个新函数，而不是修改现有的 request_irq()

The quick_check_handler
checks to see if the interrupt was from the device, returning IRQ_NONE
if it isn’t. It can also return IRQ_HANDLED
if no further processing is required or IRQ_WAKE_THREAD
to wake the handler thread. One other return code was added to simplify converting to a threaded handler. A quick_check_handler
can be developed prior to the handler
being converted; in that case, it returns IRQ_NEEDS_HANDLING
(instead of IRQ_WAKE_THREAD
) which will call the handler in the usual way.

（译者注，以下有关 quick_check_handler

。它也可以返回 IRQ_HANDLED

（即按照原有方式运行 handler
），则可以在 quick_check_handler

（而不是 IRQ_WAKE_THREAD
）。

request_threaded_irq()
will create a thread for the interrupt and put a pointer to it in the struct irqaction
. In addition, a pointer to the struct irqaction
has been added to the task_struct
so that handlers can check the action
flags for newly arrived interrupts. That reference is also used to prevent thread crashes from causing an oops. One of the few complaints seen so far about the proposal was a concern about wasting four or eight bytes
in each task_struct
that was not an interrupt handler (i.e. the vast majority). That structure could be split into two types, one for the kernel and one for user space, but it is unclear whether that will be necessary.

request_threaded_irq()

），以便中断处理函数可以检查对应中断的 action

3.5

Andi Kleen has a more general concern
that threaded interrupt handlers will lead 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 were relatively few comments, but most seemed in favor—perhaps many are waiting to see the converted driver as Gleixner promises to deliver “real soon”. If major obstacles don’t materialize, one would guess the linux-next
tree would be a logical next step, possibly followed by mainline merging for 2.6.29.

Andi Kleen 更加 关注