Linux设备驱动程序之中断下半部

中断处理程序的局限

1. 中断处理程序以异步的方式执行，并且它有可能会打断其他重要代码的执行，因此，为了避免被打段的代码停止时间过长，中断处理程序应该执行的越快越好；

2. 如果当前有一个中断处理程序在执行，在最好的情况下(没有设置IRQF_DISABLED)，与该中断同级别的其他中断就会被屏蔽，在最坏情况下(设置了IRQF_DISABLED)，当前处理器上所有其他中断都会被屏蔽；因为禁止中断后，硬件与操作系统无法通信，因此，中断处理程序执行的越快越好；

3. 由于中断处理程序往往需要对硬件进行操作，所以它们通常有很高的时限要求；

4. 中断处理程序不在进程上下文中运行，所以它们不能阻塞，这限制了它们所做的的事情；

下半部

下半部的任务就是执行与中断处理密切相关但是中断处理程序本身不执行的工作；在理想的情况下，最好是中断处理程序将所有工作都交给下半部执行，因为我们希望在中断处理程序中完成的工作越少越好，我们期望中断处理程序能够尽快的返回；

中断处理程序和下半部之间划分借鉴：

1. 如果一个任务对事件非常敏感，则将其放在中断处理程序中；

2. 如果一个任务和硬件相关，那么将其放在中断处理程序中；

3. 如果一个任务要保证不被其他中断(特别是同级中断)打断，那么将其放在中断处理程序中；

4. 其他所有任务，考虑放置在下半部执行；

下半部的方式和选择

下半部提供了三种实现方式：软中断、tasklet和工作队列；tasklet基于软中断实现，所以两者很接近；工作队列机制与它们完全不同，它靠内核线程实现；

软中断体用的执行序列化的保障最少，这就要求软中断处理函数必须格外小心地采取一些步骤确保共享数据的安全，两个甚至更多相同类型的软中断有可能在不同的处理器上同时执行；如果被考察的代码本身多线索化的工作做得非常好，比如网络子系统，它完全使用单处理器变量，那么软中断就是非常好的选择；对于时间要求严格和执行频率很高的应用来说，它执行得也最快；

如果代码多线索化考虑的并不充分，那么选择tasklet意义更大；它的接口非常简单，而且，由于两个同种类型的tasklet不能同时执行，所以实现起来也会简单一些；tasklet是有效的软中断，但不能并发执行；驱动程序开发者应当尽可能的选择tasklet而不是软中断；当然，如果准备利用每处理器变量，以确保软中断安全的在多个处理器上并发的运行，那么还是选择软中断；

如果需要把任务退后到进程上下文中完成，那么在这三者中就只能选择工作队列了，如果进程上下文并不是必须条件(也就是如果不需要睡眠)，那么软中断和tasklet可能更合适；工作队列造成的开销最大，因为它要牵扯到内核线程甚至上下文切换；这并不是说工作队列效率低，如果每秒钟有几千次中断，那么其他机制可能更合适一些；

简单的说，一般驱动程序编写者需要做两个选择：首先，是不是需要一个可调度的实体来执行需要推后完成的工作-从根本上说，有休眠的需要吗？有，工作队列就是唯一选择；否则，最好用tasklet；要是必须专注性能的提高，那就考虑软中断；