http://www.uml.org.cn/embeded/201304021.asp
1 中断和异常
产生的位置 | 发生的时刻 | 时序 | |
中断 | CPU外部 | 随机 | 异步 |
异常 | CPU内部 | 一条指令终止执行后 | 同步 |
中断(异常)一般分为异步中断(一般由硬件引起)和同步中断(一般由处理器本身引起)。
异步中断(中断):CPU处理中断的时间过长,所以先将硬件复位,使硬件可以继续自己的工作,然后在适当时候处理中断请求中耗时的部分。
举个例子:网卡的工作原理
网卡收到数据包后,向CPU发出中断信号,请求处理接收到的数据包
CPU将收到的数据包拷贝到内存后,即通知网卡继续工作
至于数据包拷贝至内存后的处理会在适当的时候进行
这样做避免了处理数据包时间过长导致网卡接收数据包速度变慢。
同步中断(异常):CPU处理完中断请求的所有工作后才反馈硬件
举个例子:系统异常处理(比如运算中的除0操作)
应用程序出现异常后,需要内核来处理
内核调用相应的异常处理函数来处理异常
处理完后终了应用程序或者给出message
同步中断应该处理能很快完成的一种中断。
2 中断
2.1 中断定义
为了提高CPU和外围硬件(硬盘,键盘,鼠标等等)之间协同工作的性能,引入了中断的机制。没有中断的话,CPU和外围设备之间协同工作可能只有轮询这个方法:CPU定期检查硬件状态,需要处理时就处理,否则就跳过。当硬件忙碌的时候,CPU很可能会做许多无用功(每次轮询都是跳过不处理)。中断机制是硬件在需要的时候向CPU发出信号,CPU暂时停止正在进行的工作,来处理硬件请求的一种机制。
2.2 中断相关函数
1 注册中断的函数2 释放中断的函数
3 中断处理程序的声明
4 执行流程函数
2.2.1 中断注册函数
request_irq用于实现中断的注册功能:
/*
* irg - 表示要分配的中断号
* handler - 实际的中断处理程序
* flags - 标志位,表示此中断的具有特性
* name - 中断设备名称的ASCII 表示,这些会被/proc/irq和/proc/interrupts文件使用
* dev - 用于共享中断线,多个中断程序共享一个中断线时(共用一个中断号),依靠dev来区别各个中断程序
* 返回值:
* 执行成功:0
* 执行失败:非0
*/
int request_irq(unsigned int irq,
irq_handler_t handler,
unsigned long flags,
const char* name,
void *dev)
a)中断注册(中断标志)
在flags参数中,可以选择一些与中断管理有关的选项,如:
1)IRQF_DISABLED(SA_INTERRUPT)
如果设置该位,表示是一个“快速”中断处理程序;如果没有设置这位,那么是一个“慢速”中断处理程序。
2)IRQF_SHARED(SA_SHIRQ)
该位表明中断可以在设备间共享。
b)快速/慢速中断
这两种类型的中断处理程序的主要区别在于:快速中断保证中断处理的原子性(不被打断),而慢速中断则不保证。换句话说,也就是“开启中断”标志位(处理器IF)在运行快速中断处理程序时是关闭的,因此在服务该中断时,不会被其他类型的中断打断;而调用慢速中断处理时,其它类型的中断仍可以得到服务。
c) 共享中断
共享中断就是将不同的设备挂到同一个中断信号线上。Linux对共享的支持主要是为PCI设备服务。共享中断也是通过request_irq函数来注册的,但有三个特别之处:
1)申请共享中断时,必须在flags参数中指定 IRQF_SHARED位
2)dev_id参数必须是唯一的。
3)共享中断的处理程序中,不能使用disable_irq(unsigned int irq) 为什么? 如果使用了这个函数,共享中断信号线的其它设备将同样无法使用中断,也就无法正常工作了。
2.2.2 释放中断函数
void free_irq(unsigned int irq, void *dev)
如果不是共享中断线,则直接删除irq对应的中断线。
如果是共享中断线,则判断此中断处理程序是否中断线上的最后一个中断处理程序,
是最后一个中断处理程序 -> 删除中断线和中断处理程序
不是最后一个中断处理程序 -> 删除中断处理程序
2.2.3 中断处理程序的声明
1) 不能向用户空间发送或接受数据
2) 不能使用可能引起阻塞的函数
3) 不能使用可能引起调度的函数
/*
* 中断处理程序的声明
* @irp - 中断处理程序(即request_irq()中handler)关联的中断号
* @dev - 与 request_irq()中的dev一样,表示一个设备的结构体
* 返回值:
* irqreturn_t - 执行成功:IRQ_HANDLED 执行失败:IRQ_NONE
*/
static irqreturn_t intr_handler(int, irq, void *dev)
2.2.4 执行流程函数
中断处理的过程主要涉及3函数:
do_IRQ 与体系结构有关,对所接收的中断进行应答
handle_IRQ_event 调用中断线上所有中断处理
ret_from_intr 恢复寄存器,将内核恢复到中断前的状态
2.3 最简单的中断机制
最简单的中断机制就是像芯片手册上讲的那样,在中断向量表中填入跳转到对应处理函数的指令,然后在处理函数中实现需要的功能。类似下图:这种方式在原来的单片机课程中常常用到,一些简单的单片机系统也是这样用。
它的好处很明显,简单,直接。
2.4 下半部
Linux中断下半部处理有三种方式: 软中断、tasklet、工作队列。
随着系统的不断复杂,中断处理函数要做的事情也越来越多,多到都来不及接收新的中断了。于是发生了中断丢失,这显然不行,于是产生了新的机制:分离中断接收与中断处理过程。中断接收在屏蔽中断的情况下完成;中断处理在时能中断的情况下完成,这部分被称为中断下半部。
从上图中看,只看int0的处理。Func0为中断接收函数。中断只能简单的触发func0,而func0则能做更多的事情,它与funcA之间可以使用队列等缓存机制。当又有中断发生时,func0被触发,然后发送一个中断请求到缓存队列,然后让funcA去处理。
由于func0做的事情是很简单的,所以不会影响int0的再次接收。而且在func0返回时就会使能int0,因此funcA执行时间再长也不会影响int0的接收。
2.4.1 软中断
下面看看linux中断处理。作为一个操作系统显然不能任由每个中断都各自为政,统一管理是必须的。我们不可中断部分的共同部分放在函数do_IRQ中,需要添加中断处理函数时,通过request_irq实现。下半部放在do_softirq中,也就是软中断,通过open_softirq添加对应的处理函数。
2.4.2 tasklet
旧事物跟不上历史的发展时,总会有新事物出现。随着中断数的不停增加,软中断不够用了,于是下半部又做了进化。软中断用轮询的方式处理。假如正好是最后一种中断,则必须循环完所有的中断类型,才能最终执行对应的处理函数。显然当年开发人员为了保证轮询的效率,于是限制中断个数为32个。为了提高中断处理数量,顺道改进处理效率,于是产生了tasklet机制。
Tasklet采用无差别的队列机制,有中断时才执行,免去了循环查表之苦。
CDMA因为频谱重叠问题,必须降功率。而功率降低后,又发现原来功率低了有助于环保。
Tasklet作为一种新机制,显然可以承担更多的优点。正好这时候SMP越来越火了,因此又在tasklet中加入了SMP机制,保证同种中断只
在一个cpu上执行。在软中断时代,显然没有这种考虑。因此同一种中断可以在两个cpu上同时执行,很可能造成冲突。
总结下tasklet的优点:
(1)无类型数量限制;
(2)效率高,无需循环查表;
(3)支持SMP机制;
2.4.3 工作队列
前面的机制不论如何折腾,有一点是不会变的。它们都在中断上下文中。什么意思?说明它们不可挂起。而且由于是串行执行,因此只要有一个处理时间较长,则会导致其他中断响应的延迟。为了完成这些不可能完成的任务,于是出现了工作队列。工作队列说白了就是一组内核线程,作为中断守护线程来使用。多个中断可以放在一个线程中,也可以每个中断分配一个线程。工作队列对线程作了封装,使用起来更方便。因为工作队列是线程,所以我们可以使用所有可以在线程中使用的方法。
Tasklet其实也不一定是在中断上下文中执行,它也有可能在线程中执行。
假如中断数量很多,而且这些中断都是自启动型的(中断处理函数会导致新的中断产生),则有可能cpu一直在这里执行中断处理函数,会导致用户进程永远得不到调度时间。
为了避免这种情况,linux发现中断数量过多时,会把多余的中断处理放到一个单独的线程中去做,就是ksoftirqd线程。这样又保证了中断不多时的响应速度,又保证了中断过多时不会把用户进程饿死。
问题是我们不能保证我们的tasklet或软中断处理函数一定会在线程中执行,所以还是不能使用进程才能用的一些方法,如放弃调度、长延时等。
3 异常
xxx