将中断处理移到线程中

09-07-2013
Yang Honggang<eagle.rtlinux@gmail.com>
---------------------------------------
源文:
Moving interrupts to threads
By Jake Edge 10-08-2008
http://lwn.net/Articles/302043/
---------------------------------------

将中断处理移到线程中

因为在处理一个中断时，其他中断就被阻塞了，所以对硬件中断的处理是内核延迟的主要来源。
为此，rt tree提供了一个称为中断处理函数线程化的特性。该特性旨在减少中断关闭的时间，
将中断的大部分处理放到内核线程中。但是并不是仅仅rt内核对低延迟感兴趣，所以中断线程化
也被提议加入主线内核。

中断线程化的好处之一是降低延迟，但是这并不是唯一的好处。最大的好处可能就是它简化或
避免了中断处理的"hard"和"soft"之间的锁，从而降低了复杂度。中断线程化有利于内核的
可调试特性，它终将导致tasklet从Linux内核中删除。为此，Thomas Gleixner等提出了一系列
的补丁,并寻求相关建议，来将中断线程化加入主线内核。

传统的中断处理中，中断顶半部("hard" irq)用于响应硬件中断，中断底半部("soft" irq)由
顶半部调度用来作进一步的处理。顶半部执行时，要关闭中断。所以，顶半部要尽可能的小，来
保证系统的响应时间。而中断线程化，进一步减少了顶半部的工作。它的顶半部由一个"快速检测函数"
组成。而处理函数仅仅用于确认中断来自于我们关注的设备。这样，它仅仅需要应答硬件中断和
告知内核需要唤醒对应的中断处理线程。

在rt tree中，几乎所有的驱动都被转化为使用内核线程处理中断。Gleixner的补丁建议对此改变
可选--由驱动的维护人决定如何做。自动转化驱动不一定受到所有维护人的欢迎，也有另一个不足，
正如同Gleixner所写:"当中断处理函数利用了tasklet/softirq，并简化了锁时，中断线程化才有意义。"

驱动要申请一个线程化的中断处理函数时，要使用：

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)
该函数本质上和request_irq()相同，只是附加了quick_check_handler。正如同Linus Torvalds在
本年度的内核峰会上要求的，需要增加一个新的函数而不是将众多的驱动修改为使用新的
request_irq()。

quick_check_handler检查中断是否来自于我们关注的设备，返回IRQ_NONE表示不是我们关注的设备产生了中断。
返回IRQ_HANDLED标示不需要进一步的处理。返回IRQ_WAKE_THREAD标示唤醒中断处理线程。增加了另一个
返回码来简化向中断线程化转化。这样，quick_check_handler就可以在中断处理被转化前被开发。
在这种情况下，它会返回IRQ_NEEDS_HANDLING（而不是IRQ_WAKE_THREAD)。这时会调用像传统的中断处理中
一样调用原来的处理函数。

request_thread_irq()会为中断创建一个线程，并将指向该线程的指针放在struct irqaction中。
另外，一个指向struct irqaction的指针也被添加到task_struct中。这样，处理函数就可以检查
新到来的中断的动作标志。该引用也来防止线程引发oops后崩溃。对于该提议的抱怨之一就是“浪费了
非中断处理线程（占据大部分）的task_struct 结构的4个或者8个字节”。该结构应该分成两种，
一种用于内核，另一种用于用户空间。但是，这是否有必要还不清楚。

Andi Kleen的担心更为普遍，中断线程化会导致低质量的代码：
 "诚实地讲，长远地看，中断线程化将鼓励低质量的中断代码"。然而，他好像是少数者。
 ...