《Linux设备驱动程序》（十六）-中断处理

设备与处理器之间的工作通常来说是异步，设备数据要传递给处理器通常来说有以下几种方法：轮询、等待和中断。

让CPU进行轮询等待总是不能让人满意，所以通常都采用中断的形式，让设备来通知CPU读取数据。

2.6内核的函数参数与现在的参数有所区别，这里都主要介绍概念，具体实现方法需要结合具体的内核版本。

request_irq函数申请中断，返回0表示申请成功，其他返回值表示申请失败，其具体参数解释如下：

flags 掩码可以使用以下几个：

快速和慢速处理例程 ：现代内核中基本没有这两个概念了，使用SA_INTERRUPT位后，当中断被执行时，当前处理器的其他中断都将被禁止。通常不要使用SA_INTERRUPT标志位，除非自己明确知道会发生什么。

共享中断 ：使用共享中断时，一方面要使用SA_SHIRQ位，另一个是request_irq中的dev_id必须是唯一的，不能为NULL。这个限制的原因是：内核为每个中断维护了一个共享处理例程的列表，例程中的dev_id各不相同，就像设备签名。如果dev_id相同，在卸载的时候引起混淆（卸载了另一个中断），当中断到达时会产生内核OOP消息。

共享中断需要满足以下一个条件才能申请成功：

当不需要使用该中断时，需要使用free_irq释放中断。

通常我们会在模块加载的时候申请安装中断处理例程，但书中建议：在设备第一次打开的时候安装，在设备最后一次关闭的时候卸载。

如果要查看中断触发的次数，可以查看 /proc/interrupts 和 /proc/stat。

书中讲述了如何自动检测中断号，在嵌入式开发中通常都是查看原理图和datasheet来直接确定。

自动检测的原理如下：驱动程序通知设备产生中断，然后查看哪些中断信号线被触发了。Linux提供了以下方法来进行探测：

探测工作耗时较长，建议在模块加载的时候做。

中断处理函数和普通函数其实差不多，唯一的区别是其运行的中断上下文中，在这个上下文中有以下注意事项：

中断处理函数典型用法如下：

中断处理函数的参数和返回值含义如下：

返回值主要有两个：IRQ_NONE和IRQ_HANDLED。

对于中断我们是可以进行开启和关闭的，Linux中提供了以下函数 *** 作单个中断的开关：

该方法可以在所有处理器上禁止或启用中断。

需要注意的是：

如果要关闭当前处理器上所有的中断，则可以调用以下方法：

local_irq_save 会将中断状态保持到flags中，然后禁用处理器上的中断；如果明确知道中断没有在其他地方被禁用，则可以使用local_irq_disable，否则请使用local_irq_save。

locat_irq_restore 会根据上面获取到flags来恢复中断；local_irq_enable 会无条件打开所有中断。

在中断中需要做一些工作，如果工作内容太多，必然导致中断处理所需的时间过长；而中断处理又要求能够尽快完成，这样才不会影响正常的系统调度，这两个之间就产生了矛盾。

现在很多 *** 作系统将中断分为两个部分来处理上面的矛盾：顶半部和底半部。

顶半部就是我们用request_irq来注册的中断处理函数，这个函数要求能够尽快结束，同时在其中调度底半部，让底半部在之后来进行后续的耗时工作。

顶半部就不再说明了，就是上面的中断处理函数，只是要求能够尽快处理完成并返回，不要处理耗时工作。

底半部通常使用tasklet或者工作队列来实现。

tasklet的特点和注意事项：

工作队列的特点和注意事项：

cpu上下文是指cpu在运行任何任务之前都要依赖的环境。cpu上下文包括两个部分，cpu寄存器和程序计数器。cpu上下文切换，指的就是把上一个任务寄存器和程序计数器的值保存起来（保存在内存特定的数据结构中）然后设置新任务cpu寄存器和程序计数器值的过程。

每次上下文切换需要几十纳秒到数微妙的cpu时间。

根据任务类型的不同，cpu上下文切换可以分为进程上下文切换，线程上下文切换，中断上下文切换。

还有一种情况比较特殊，系统调用的过程中也发生了上下文切换，这种切换被称为特权模式切换。

一个进程从用户态到内核态的转变，需要通过系统调用来完成。

从用户态切换到内核态，cpu寄存器原来的用户态的指令位置需要保存起来，然后加载内核态的指令位置到cpu寄存器中。

系统调用结束后，cpu寄存器需要恢复原来保存的用户态，然后再切换到用户空间，继续运行。所以，一次系统调用的过程，其实是发生了两次cpu上下文切换。

进程的上下文切换比系统调用多了一步，在保存当前进程的内核状态和cpu寄存器之前，需要先把该进程的虚拟内存，栈等保存下来。而加载了下一个进程的内核态之后，还需要刷新进程的虚拟内存和用户栈。

线程与进程的最大区别在于，线程是调度的基本单位，而进程则是资源拥有的基本单位。内核中的任务调度，实际上调度的对象是线程。

当进程拥有多个线程时，这些线程会共享相同的虚拟内存和全局变量资源。这些资源在上下文切换时是不需要修改的。另外，线程也有自己的私有数据，比如栈和寄存器等。这些在上下文切换也是需要保存的。

线程的上下文切换分为两种情况：

1 ) 前后两个线程属于不同的进程。这时，切换线程就和切换进程一样。

2 ) 前后两个线程属于同一个进程。因为虚拟内存是共享的，所以在切换时，虚拟内存这些共享资源保存不动，只要切换线程的私有数据，寄存器等不共享的数据。

为了快速响应硬件的事件，中断处理会打断进程的正常调度和执行，转而执行中断处理程序。对于同一个cpu来说，中断处理比进程拥有更高的优先级。

跟进程上下文切换不同，内核的中断上下文切换并不涉及到进程的用户态。进程的用户态切换由cpu硬件来处理。所以即便中断过程打断了一个正处在用户态的进程，也不需要保存和恢复这个进程的虚拟内存，全局变量等用户态资源。这些由cpu硬件来保存和恢复。

参考资料：

在 Linux性能分析-平均负载 中，提到过一种导致平均负载升高的情况，就是有大量进程或线程等待cpu调度。

为什么大量进程或者线程等待CPU调度会导致负载升高呢？

当大量进程或者线程等待调度时，cpu需要更加频繁的切换任务，在切换任务的过程中，需要保存上一个任务的context到内核中，并且恢复当前任务的context，这种保存和恢复的 *** 作也是需要cpu来执行的，导致cpu都消耗在了 保存上文和恢复下文 这个过程中。

除了进程和线程导致的上下文切换以外，硬件产生的中断事件也会导致上下文切换。并且中断事件的优先级是高于线程和进程任务的。

这篇文章会模拟测试这种情况。

vmstat是一个观测总体上下文切换状况的命令。

下面指令可以每隔5秒输出一组数据。

重点关注列含义：

使用vmstat关注到了整体的情况，接下来可以使用pidstat关注具体线程的情况

注：pidstat -wt 可以输出线程的情况

重点关注列含义：

系统环境：

首先安装sysbench，使用sysbench，我们可以模拟一个进程内多线程调度引起的上下文切换问题。

安装好后，执行下面命令

查看下vmstat和pidstat

观察vmstat结果，可以看到

观察pidstat两类结果，可以发现

整体结果符合我们的预期。

针对in列显著提高，可以查看 /proc/interrupts 文件，里面记录了中断相关的数据，这些数据记录的是从上次启动到现在的累加值。

我们把系统重新启动下，看下空闲状态下的文件

当执行sysbench命令后，并运行一段时间后，该文件如下

其中，LOC和RES显著升高

RES表示，唤醒空闲状态的CPU来调度新的任务运行，和我们模拟的过多任务调度有关。

LOC不太理解，暂时先放在这里。

---