上半部与下半部

又想中断处理程序运行得快，又想中断处理程序完成的工作量多，这两个目的显然有所抵触。鉴于两个目的之间存在此消彼长的矛盾关系，所以我们一般把中断处理切为两个部分或两半。

中断处理程序是上半部。接受到一个中断，他就立即开始执行，但只做严格时限的工作。例如对接受的中断进行应答或复位硬件，这些工作都是在所有中断被禁止的情况下完成的。能够被允许稍后完成的工作会推迟到下半部(bottom half)去。此后，在合适的时机，下半部会被开中断执行。Linux提供了实现下半部的各种机制。

1、"下半部"的起源

最早的Linux只提供"bottom half"这种机制用于实现下半部。这个名字在那时毫无异议，因为但是它是将工作推后的唯一方法。这种机制也被称为"BH".BH接口非常简单。他提供一个静态创建，由32个bottom halves组成的链表。上半部通过一个32位整数中的一位来标示出哪个bottom half可以执行。每个BH都在全局范围内进行同步。即使分属于不同的处理器，也不允许任何两个bottom half同事执行。这种机制使用方便却不够灵活，简单却有性能瓶颈。

2、任务队列

不久，内核开发者们就引入了任务队列（task queue）机制来实现工作的推后执行。并用它代替BH机制。内核为此定义了一组队列都包含一个由等待调用的函数组成链表。根据其所处队列的位置，这些函数会在某个时刻执行。驱动程序可以把它们自己的下半部注册到合适的队列上去。这种机制表现得还不错，但仍不够灵活，没法代替整个BH接口。对于一些性能要求较高的子系统，像网络部分，它也不能胜任。

3、软中断和tasklet

在2.3这个开发板中，内核开发者引入了软中断(softirqs)和tasklet。如果无需考虑过去开发的驱动程序兼容的话，软中断和tasklet可以完全代替BH接口。软中断是一组静态定义的下半部接口，有32个，可以在所有处理器上同时执行--即使两个类型相同也可以。tasklet这一名称取得很槽糕，让人费解，他们是一种基于软中断实现的灵活性强，动态创建的下半部实现机制。