《Linux内核的设计与实现》第八章笔记

第八章 下半部和推后执行的工作

• 中断处理程序以异步方式执行，并且它有可能会打断其他重要代码（甚至包括其他中断处理程序）的执行。因此，为了避免被打断的代码停止时间过长，中断处理程序应该执行得越快越好。
• 如果当前有一个中断处理程序正在执行，在最好的情况下（如果IRQF_DISABLED设有被设置），与该中断同级的其他中断会被屏蔽，在最坏的情况下（如果设置了IRQF_DISABLED），当前处理器上所有其他中断都会被屏蔽。因为禁止中断后硬件与操作系统无法通信，因此，中断处理程序执行得越快越好。
• 由于中断处理程序往往需要对硬件进行操作，所以它们通常有很高的时限要求。
• 中断处理程序不在进程上下文中运行，所以它们不能阻塞。这限制了它们所做的事情。

现在，为什么中断处理程序只能作为整个硬件中断处理流程一部分的原因就很明显了。操作系统必须有一个快速、异步、简单的机制负责对硬件做出迅速响应并完成那些时间要求很严格的操作。中断处理程序很适合于实现这些功能，可是，对于那些其他的、对时间要求相对宽松的任务，就应该推后到中断被激活以后再去运行。

8.1 下半部

遗憾的是，并不存在严格明确的规定来说明到底什么任务应该在哪个部分中完成——如何做决定完全取决于驱动程序开发者自己的判断。尽管在理论上不存在什么错误，但轻率的实现效果往往不很理想。记住，中断处理程序会异步执行，并且在最好的情况下它也会锁定当前的中断线。因此将中断处理程序持续执行的时间缩短到最小程度显得非常重要。对于在上半部和下半部之间划分工作，尽管不存在某种严格的规则，但还是有一些提示可供借鉴：

• 如果一个任务对时间非常敏感，将其放在中断处理程序中执行。
• 如果一个任务和硬件相关，将其放在中断处理程序中执行。
• 如果一个任务要保证不被其他中断（特别是相同的中断）打断，将其放在中断处理程序中执行。
• 其他所有任务，考虑放置在下半部执行。

8.1.1 什么时候执行下半部

但具体放到以后什么时候去做呢？在这里，以后仅仅用来强调不是马上而已，理解这一点相当重要。下半部并不需要指明一个确切时间，只要把这些任务推迟一点，让它们在系统不太繁忙并且中断恢复后执行就可以了。通常下半部在中断处理程序一返回就会马上运行。下半部执行的关键在于当它们运行的时候，允许响应所有的中断。

8.1.2 下半部的环境

和上半部只能通过中断处理程序实现不同，下半部可以通过多种机制实现。这些用来实现下半部的机制分别由不同的接口和子系统组成。在第7章中，我们了解到实现中断处理程序的方法只有一种，但在本章中你会发现，实现一个下半部会有许多不同的方法。实际上，在Linux发展过程中曾经出现过多种下半部机制。本章讨论在2.6版内核中的下半部实现机制：软中断、tasklets、工作队列。

内核定时器
另外一个可以用于将工作推后执行的机制是内核定时器。不像本章到目前为止介绍到的所有这些机制，内核定时器把操作推迟到某个确定的时间段之后执行。也就是说，尽管本章讨论的其他机制可以把操作推后到除了现在以外的任何时间进行，但是当你必须保证在一个确定的时间段过去以后再运行时，你应该使用内核定时器。

8.2 软中断

软中断是tasklets实现的基础，它的特性包括：

1. 产生后并不是马上可以执行，必须要等待内核的调度才可以执行。
2. 软中断不能被自己打断，只能被硬件中断打断（上半部）。
3. 可以并发运行在多个cpu上（即使同一类型也可以）。所以软中断必须设计为可重入的函数（允许多个CPU同时操作），因此也需要使用自旋锁来保护其数据结构。

8.2.1 软中断的实现

软中断是在编译期间静态分配的。它不像tasklets那样能被动态地注册或注~销。软中断由softirq_action结构表示，它定义在<linux/interupt.h>中：

struct softirq_action{
    void（*action）（struct softirq_action *）;
};

kernell/softirq.c中定义了一个包含有32个该结构体的数组。

static struct softirq_action softirq_vec[NR_SOFTIRQS];

每个被注册的软中断都占据该数组的一项，因此最多可能有32个软中断。注意，这是一个定值——注册的软中断数目的最大值不能动态改变。在当前版本的内核中，这32个项中只用到9个。

1. 软中断处理程序

软中断处理程序action的函数原型如下：

void softirq_handler（struct softirq_action *）

当内核运行一个软中断处理程序的时候，它就会执行这个action函数，其唯一的参数为指向相应softirq_action结构体的指针。例如，如果my_softirq 指向softirq_vec数组的某项，那么内核会用如下的方式调用软中断处理程序中的函数：

my_softirq->action（my_softirq）;

当你看到内核把整个结构体都传递给软中断处理程序而不是仅仅传递数据值的时候，你可能会很吃惊。这个小技巧可以保证将来在结构体中加入新的域时，无须对所有的软中断处理程序都进行变动。如果需要，软中断处理程序可以方便地解析它的参数，从数据成员中提取数值。

一个软中断不会抢占另外一个软中断。实际上，唯一可以抢占软中断的是中断处理程序。不过，其他的软中断（甚至是相同类型的软中断）可以在其他处理器上同时执行。

2. 执行软中断

一个注册的软中断必须在被标记后才会执行。这被称作触发软中断（raising the softirq）。通常，中断处理程序会在返回前标记它的软中断，使其在稍后被执行。于是，在合适的时刻，该软中断就会运行。在下列地方，待处理的软中断会被检查和执行：

• 从一个硬件中断代码处返回时
• 在ksoftirqd内核线程中
• 在那些显式检查和执行待处理的软中断的代码中，如网络子系统中

不管是用什么办法唤起，软中断都要在do_softrq()中执行。该函数很简单。如果有待处理的软中断，do_softirq()会循环遍历每一个，调用它们的处理程序。

8.2.2 使用软中断

1. 分配索引

在编译期间，通过在<linux/interrupt.h>中定义的一个枚举类型来静态地声明软中断。内核用这些从0开始的索引来表示一种相对优先级。索引号小的软中断在索引号大的软中断之前执行。

建立一个新的软中断必须在此枚举类型中加入新的项。而加入时，你不能像在其他地方一样，简单地把新项加到列表的末尾。相反，你必须根据希望赋予它的优先级来决定加入的位置。习惯上，HI_SOFTIRQ通常作为第一项，而RCU_SOFTIRQ作为最后一项。新项可能插在BLOCK_SOFTIRQ和TASKLET_SOFTIRQ之间。表8-2列举出了已有的tasklet类型。

2. 注册你的处理程序

接着，在运行时通过调用open_softirq()注册软中断处理程序，该函数有两个参数：软中断的索引号和处理函数。如网络子系统，在net/coreldev.c通过以下方式注册自己的软中断：

open_softirq（NET_TX_SOFTIRQ，net_tx_action）;
open_softirq（NET_RX_SOFTIRQ，net_rx_action）;

3. 触发你的软中断

通过在枚举类型的列表中添加新项以及调用open_softirq()进行注册以后，新的软中断处理程序就能够运行。raise_softirq()函数可以将一个软中断设置为挂起状态，让它在下次调用do_sofirq()函数时投入运行。

在中断处理程序中触发软中断是最常见的形式。在这种情况下，中断处理程序执行硬件设备的相关操作，然后触发相应的软中断，最后退出。内核在执行完中断处理程序以后，马上就会调用do sonirgo0函数。于是软中断开始执行中断处理程序留给它去完成的剩余任务。

8.3 tasklet

tasklet是利用软中断实现的一种下半部机制。如果某种应用并不需要在多个CPU上并行执行，那么软中断其实是没有必要的。tasklet和软中断在本质上很相似，行为表现也相近，但是，它的接口更简单，锁保护也要求较低。它具有以下特性：

1. 一种特定类型的tasklet只能运行在一个CPU上，不能并行，只能串行执行
2. 多个不同类型的tasklet可以并行在多个CPU上
3. 软中断是静态分配的，在内核编译好后就不能改变。但tasklet就灵活得多，可以在运行时改变（比如添加模块时）

8.3.1 tasklet的实现

因为tasklet是通过软中断实现的，所以它们本身也是软中断，前面讨论过了，tasklet由两类软中断代表：HI_SOFTIRQ和TASKLET_SOFTIRQ。这两者之间唯一的实际区别在HI_SOFTIRQ类型的软中断先于TASKLET_SOFTIRQ类型的软中断执行。

1. tasklet结构体

tasklet由tasklet_struct结构表示。每个结构体单独代表一个tasklet，它在<linux/interrupt.h>中定义为：

struct tasklet_struct{
    struct tasklet_struct *next; /*链表中的下一个tasklet*/
    unsigned long state;         /*tasklet的状态*/
    atomic_t count;              /*引用计数器*/
    void（*func）（unsigned 1ong）;/*tasklet处理函数*/
    unsigned long data;          /*给tasklet处理函数的参数*/
};

结构体中的func成员是tasklet的处理程序（像软中断中的action一样），data是它唯一的参数state成员只能在0，TASKLET_STATE_SCHED和TASKLET_STATE_RUN之间取值。TASKLET_STATE_SCHED表明tasklet已被调度，正准备投入运行，TASKLET_STATE_RUN表明该tasklet正在运行。TASKLET_STATE_RUN只有在多处理器的系统上才会作为一种优化来使用，单处理器系统任何时候都清楚单个tasklet是不是正在运行（它要么就是当前正在执行的代码，要么不是）。

count成员是tasklet的引用计数器。如果它不为0，则tasklet被禁止，不允许执行；只有当它为0时，tasklet才被激活，并且在被设置为挂起状态时，该tasklet才能够执行。

2. 调度tasklet

已调度的tasklet（等同于被触发的软中断）存放在两个单处理器数据结构：tasklet_vec（普通tasklet）和tasklet_hi_vec（高优先级的tasklet），这两个数据结构都是由tasklet_struct结构体构成的链表。链表中的每个tasklet_struct代表一个不同的tasklet。

tasklet由tasklet_schedule()和tasklet_hi_schedule()函数进行调度，它们接受一个指向tasklet_struct结构的指针作为参数。两个函数非常类似（区别在于一个使用TASKLET_SOFTIRQ而另一个用HI_SOFTIRQ），在接下来的内容中我们将仔细研究怎么编写和使用tasklets。

tasklet_schedule()的执行步骤：[在上半部的中断处理函数中执行tasklet_schedule()]

1. 检查tasklet的状态是否为TASKLET_STATE_SCHED，如果是，说明tasklet已经被调度过了，函数立即返回。

2. 调用tasklet_schedule()

3. 保存中断状态，然后禁止本地中断。在我们执行tasklet代码时，这么做能够保证当tasklet_schedule()处理这些tasklet时，处理器上的数据不会弄乱。

4. 把需要调度的tasklet加到每个处理器一个的tasklet_vec链表或tasklet_hi_vec链表的表头上去。

5. 唤起TASKLET_SOFTIRQ或HI_SOFTIRQ软中断，这样在下一次调用do_softirq()时就会执行该tasklet。

6. 恢复中断到原状态并返回。

do_softirq()会尽可能早地在下一个合适的时机执行。由于大部分tasklet和软中断都是在中断处理程序中被设置成待处理状态，所以最近一个中断返回的时候看起来就是执行do_sofirq()的最佳时机。而这两个处理程序，tasklet_action()和tasklet_hi_action()，就是tasklet处理的核心。让我们观察它们做了什么：

1. 禁止中断（没有必要首先保存其状态，因为这里的代码总是作为软中断被调用，而且中断总是被激活的），并为当前处理器检索tasklet_vec或tasklet_hig_vec链表。
2. 将当前处理器上的该链表设置为NULL，达到清空的效果。
3. 允许响应中断。没有必要再恢复它们回原状态，因为这段程序本身就是作为软中断处理程序被调用的，所以中断是应该被允许的。
4. 循环遍历获得链表上的每一个待处理的tasklet。
5. 如果是多处理器系统，通过检查TASKLET_STATE_RUN来判断这个tasklet是否正在其他处理器上运行。如果它正在运行，那么现在就不要执行，跳到下一个待处理的tasklet去（回忆一下，同一时间里，相同类型的tasklet只能有一个执行）。
6. 如果当前这个tasklet没有执行，将其状态设置为TASKLET_STATE_RUN，这样别的处理器就不会再去执行它了。
7. 检查count值是否为0，确保tasklet没有被禁止。如果tasklet被禁止了，则跳到下一个挂起的tasklet去。
8. 我们已经清楚地知道这个tasklet没有在其他地方执行，并且被我们设置成执行状态，这样它在其他部分就不会被执行，并且引用计数为0，现在可以执行tasklet的处理程序了。
9. tasklet运行完毕，清除tasklet的state域的TASKLET_STATE_RUN状态标志。
10. 重复执行下一个tasklet，直至没有剩余的等待处理的tasklet。

8.3.2 使用tasklet

1. 声明你自己的tasklet

你既可以静态地创建tasklet，也可以动态地创建它。选择哪种方式取决于你到底是有（或者是想要）一个对tasklet的直接引用还是间接引用。如果你准备静态地创建一个tasklet（也就是有一个它的直接引用），使用下面<linux/interrupt.h>中定义的两个宏中的一个：

DECLARE_TASKLET（name,func,data）;
DECLARE_TASKLET_DISABLED（name,func,data）;

这两个宏都能根据给定的名称静态地创建一个tasklet_struct结构。当该tasklet被调度以后，给定的函数func会被执行，它的参数由data给出，这两个宏之间的区别在于引用计数器的初始值设置不同。前面一个宏把创建的tasklet的引用计数器设置为0，该tasklet处于激活状态。另一个把引用计数器设置为1，所以该tasklet处于禁止状态。

2. 编写你自己的tasklet处理程序

tasklet处理程序必须符合规定的函数类型：

void tasklet_handler（unsigned long data）

3. 调度你自己的tasklet

通过调用tasklet_schedule()函数并传递给它相应的tasklt_struct的指针，该tasklet就会被调度以便执行：

tasklet_schedule（&my_tasklet）;/*把my_tasklet标记为挂起*/

4. ksoftirqd

每个处理器都有一组辅助处理软中断（和tasklet）的内核线程。当内核中出现大量软中断的时候，这些内核进程就会辅助处理它们。

我们前面曾经阐述过，对于软中断，内核会选择在几个特殊时机进行处理。而在中断处理程序返回时处理是最常见的。软中断被触发的频率有时可能很高（像在进行大流量的网络通信期间）。更不利的是，处理函数有时还会自行重复触发。也就是说，当一个软中断执行的时候，它可以重新触发自己以便再次得到执行（事实上，网络子系统就会这么做），如果软中断本身出现的频率就高，再加上它们又有将自己重新设置为可执行状态的能力，那么就会导致用户空间进程无法获得足够的处理器时间，因而处于饥饿状态。而且，单纯的对重新触发的软中断采取不立即处理的策略，也无法让人接受。当软中断最初提出时，就是一个让人进退维谷的问题，亟待解决，而直观的解决方案又都不理想。

在内核中实现的方案是不会立即处理重新触发的软中断。在从中断返回的时候，内核和平常一样，也会检查所有挂起的软中断并处理它们。但是，任何自行重新触发的软中断都不会马上处理，它们被放到下一个软中断执行时去处理。而这个时机通常也就是下一次中断返回的时候，这等于是说，一定得等一段时间，新的（或者重新触发的）软中断才能被执行。

而作为改进，当大量软中断出现的时候，内核会唤醒一组内核线程来处理这些负载。这些线程在最低的优先级上运行（nice值是19），这能避免它们跟其他重要的任务抢夺资源。但它们最终肯定会被执行，所以，这个折中方案能够保证在软中断负担很重的时候，用户程序不会因为得不到处理时间而处于饥饿状态，相应的，也能保证“过量”的软中断终究会得到处理。

每个处理器都有一个这样的线程。所有线程的名字都叫做ksoftirqd/n，区别在于n，它对应的是处理器的编号。在一个双CPU的机器上就有两个这样的线程，分别叫ksoftirqd/o和ksoftirqd/1，为了保证只要有空闲的处理器，它们就会处理软中断，所以给每个处理器都分配一个这样的线程。一旦该线程被初始化，它就会执行类似下面这样的死循环：

for(;;){
    if(!softirq_pending(cpu))
        schedule();
    set_current_state(TASK_RUNNING);
    while(softirq_pending(cpu)){
        do softirg();
        if(need_resched())
            schedule();
    }
}

只要有待处理的软中断（由softirq_pending()函数负责发现），ksoftirq就会调用do_softirq()去处理它们。通过重复执行这样的操作，重新触发的软中断也会被执行。如果有必要的话，每次迭代后都会调用schedule()以便让更重要的进程得到处理机会。当所有需要执行的操作都完成以后，该内核线程将自己设置为TASK_INTERRUPTIBLE状态，唤起调度程序选择其他可执行进程投入运行。

只要do_softirq()函数发现已经执行过的内核线程重新触发了它自己，软中断内核线程就会被唤醒。

8.4 工作队列

工作队列是另外一种将工作推后执行的形式，他和我们前面讨论的所有其他形式都不同。由于中断上下文处于内核态，没有进程切换，所以如果软中断一旦睡眠或者阻塞，将无法退出这种状态，导致内核整个僵死。所以可阻塞函数不能运行在中断上下文，必须运行在进程上下文中。

工作队列可以把工作推后，交由一个内核线程去执行——这个下半部总是会在进程上下文中执行。这样，通过工作队列执行的代码能占尽进程上下文的所有优势。最重要的是工作队列允许重新调度或是睡眠。

用户线程：指不需要内核支持而在用户程序中实现的线程，其不依赖于操作系统核心，应用进程利用线程库创建和管理用户线程。不需要进行用户态与内核态的切换，始终运行在用户态。

内核线程：线程的所有管理操作由操作系统内核完成。内核保存线程的状态和上下文信息，当一个线程阻塞时，内核可以调度进程的其他线程运行。

如果你需要用一个可以重新调度的实体来执行你的下半部处理，你应该使用工作队列。它是唯一能在进程上下文中运行的下半部实现机制，也只有它才可以睡眠。这意味着在你需要获得大量的内存时，在你需要获取信号量时，在你需要执行阻塞式的I/O操作时，它都会非常有用。如果你不需要用一个内核线程来推后执行工作，那么就考虑使用tasklet吧。

8.4.1 工作队列的实现

工作队列子系统是一个用于创建内核线程的接口，通过它创建的进程负责执行由内核其他部分排到队列里的任务。它创建的这些内核线程称作工作者线程（worker thread）。工作队列可以让你的驱动程序创建一个专门的工作者线程来处理需要推后的工作。不过，工作队列子系统提供了一个缺省的工作者线程来处理这些工作。因此，工作队列最基本的表现形式，就转变成了一个把需要推后执行的任务交给特定的通用线程的这样一种接口。

缺省的工作者线程叫做events/n，这里n是处理器的编号；每个处理器对应一个线程。例如，单处理器的系统只有events/0这样一个线程，而双处理器的系统就会多一个events/1线程。缺省的工作者线程会从多个地方得到被推后的工作。许多内核驱动程序都把它们的下半部交给缺省的工作者线程去做。除非一个驱动程序或者子系统必须建立一个属于它自己的内核线程，否则最好使用缺省线程。

8.4.1 工作队列的实现

1. 表示线程的数据结构

工作者线程用workqueue_struct结构表示，该结构内是一个由cpu_workqueue_struct结构组成的数组，它定义在kernel/workqueue.c中，数组的每一项对应系统中的一个处理器。

2. 表示工作的数据结构

工作用<linux/workqueue.h>中定义的work_struct结构体表示。这些结构体被连接成链表，在每个处理器上的每种类型的队列都对应这样一个链表。比如，每个处理器上用于执行被推后的工作的那个通用线程就有一个这样的链表。当一个工作者线程被唤醒时，它会执行它的链表上的所有工作。工作被执行完毕，它就将相应的work_struct对象从链表上移去。当链表上不再有对象的时候，它就会继续休眠。

所有的工作者线程都是用普通的内核线程实现的，它们都要执行worker_thread()函数。该函数在死循环中完成了以下功能：

1. 线程将自己设置为休眠状态（state被设成TASK_INTERRUPTIBLE），并把自己加入到等待队列中。
2. 如果工作链表是空的，线程调用schedule()函数进入睡眠状态。
3. 如果链表中有对象，线程不会睡眠。相反，它将自己设置成TASK_RUNNING，脱离等待队列。
4. 如果链表非空，调用run_workqueue()函数执行被推后的工作。

下一步，由run_workqueue()函数来实际完成推后到此的工作,该函数循环遍历链表上每个待处理的工作，执行链表每个节点上的work_struct中的func成员函数，然后将该节点从链表上取下来，将待处理标志位pending清零。

8.4.2 使用工作者队列

1. 创建推后的工作

首先要做的是实际创建一些需要推后完成的工作。可以通过DECLARE_WORK在编译时静态地创建该结构体：

DECLARE_WORK(name,void(*func) (void *),void *data);

这样就会静态地创建一个名为name，处理函数为func，参数为data的work_struct结构体。
同样，也可以在运行时通过指针创建一个工作：

INIT_WORK(struct work_struct *work,void(*func)(void *),void *data);

这会动态地初始化一个由work指向的工作，处理函数为func，参数为data。

2. 工作队列处理函数

工作队列处理函数的原型是：

void work_handler(void *data)

这个函数会由一个工作者线程执行。

3. 对工作进行调度

现在工作已经被创建，我们可以调度它了。想要把给定工作的处理函数提交给缺省的events工作线程，只需调用：

schedule_work(&work);

work马上就会被调度，一旦其所在的处理器上的工作者线程被唤醒，它就会被执行。有时候你并不希望工作马上就被执行，而是希望它经过一段延迟以后再执行。在这种情况下，你可以调度它在指定的时间执行：

schedule_delayed_work(&work，delay);

这时，&work指向的work_struct直到delay指定的时钟节拍用完以后才会执行。在第11章将介绍这种使用时钟节拍作为时间单位的方法。

4. 创建新的工作队列

如果缺省的队列不能满足你的需要，你应该创建一个新的工作队列和与之相应的工作者线程。由于这么做会在每个处理器上都创建一个工作者线程，所以只有在你明确了必须要靠自己的一套线程来提高性能的情况下，再创建自己的工作队列。

创建一个新的任务队列和与之相关的工作者线程，你只需调用一个简单的函数：

struct workqueue_struct *create_workqueue (const char *name);

name参数用于该内核线程的命名。比如，缺省的events队列的创建就调用的是：

struct workqueue_struct   *keventd_wq;

keventd_wg = create_workqueue("events");

这样就会创建所有的工作者线程（系统中的每个处理器都有一个），并且做好所有开始处理工作之前的准备工作。

创建一个工作的时候无须考虑工作队列的类型。在创建之后，可以调用下面列举的函数。这些函数与schedule_work()以及schedule_delayed_work()相近，唯一的区别就在于它们针对给定的工作队列而不是缺省的events队列进行操作。

int queue_work(struct workqueue_struct *wq, struct work_struct *work)
int queue_delayed_work(struct workqueue_struet *wq, struct work_struct *work, unsigned long delay)

8.5 下半部机制的选择

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