Linux 中断处理的核心：顶半部和底半部

Linux中断处理的核心:顶半部和底半部
原文链接：https://blog.csdn.net/yuesichiu/article/details/8286469

  设备的中断会打断内核中进程的正常调度和运行，系统对更高吞吐率的追求势必要求中断服务程序尽可能地短小精悍。但是，这个良好的愿望往往与现实并不吻合。在大多数真实的系统中，当中断到来时，要完成的工作往往并不会是短小的，它可能要进行较大量的耗时处理。
  为了在中断执行时间尽可能短和中断处理需完成大量工作之间找到一个平衡点,Linux将中断处理程序分解为两个半部：顶半部(op half)和底半部(bottom half)。 顶半部完成尽可能少的比较紧急的功能，它往往只是简单地读取寄存器中的中断状态并清除中断标志后就进行“登记中断”的工作。“登记中断”意味着将底半部处理程序挂到该设备的底半部执行队列中去。 这样，顶半部执行的速度就会很快，可以服务更多的中断请求。现在，中断处理工作的重心就落在了底半部的头上，它来完成中断事件的绝大多数任务。底半部几乎做了中断处理程序所有的事情，而且可以被新的中断打断，这也是底半部和顶半部的最大不同，因为顶半部往往被设计成不可中断。底半部则相对来说并不是非常紧急的，而且相对比较耗时，不在硬件中断服务程序中执行。
  顶半部是实际响应中断的过程，也就是用request_irq注册的中断例程。而底半部会在稍后比较安全的时间内执行的过程。即底半部的中断都是打开的。比较典型的情况是顶半部保存设备的数据到一个设备特定的缓存区并调度它的底半部，然后退出；这个过程是非常迅速的。然后底半部执行其他必要的工作，例如唤醒进程、启动另外的I/O操作等等。这种方法允许在底半部工作期间，顶半部还可以继续为新的中断服务。
  尽管顶半部、底半部的结合能够改善系统的响应能力，但是，僵化地认为 Linux设备驱动中的中断处理一定要分两个半部则是不对的。如果中断要处理的工作本身很少，则完全可以直接在顶半部全部完成。其他操作系统中对中断的处理也采用了类似于Linux系统的方法，真正的硬件中断服务程序都应该尽可能短。因此，许多操作系统都提供了中断上下文和非中断上下文相结合的机制，将中断的耗时工作保留到非中断上下文去执行。
   Linux 系统实现底半部的机制主要有tasklet，工作队列和软中断。 Linux 的中断处理分为两个半部，顶半部处理紧急的硬件操作，底半部处理不紧急的耗时操作。tasklet和工作队列都是调度中断底半部的良好机制，tasklet基于软中断实现。内核定时器也依靠软中断实现。内核中的延时是忙等待或者睡眠等待，为了充分利用CPU资源，使系统有更好的吞吐性能，在对延迟时间的要求并不是很精确的情况下，睡眠等待通常是值得推荐的。

  那顶半部和底半部表现在代码中到底是一个什么情况呢？我的理解是在中断中调度工作队列(或者其他机制)中的某个工作和执行一些简单的代码(这个称为顶部)，然后中断就结束了，以确保中断的高吞吐率，那中断具体要执行的事情当然就有工作队列中的任务去完成了(这个称为底部)。