虎贲小队程序猿

get along

导航

linux中断处理的上半部和下半部

设备的中断会打断内核中进程的正常调度和运行,系统对更高吞吐率的追求势必

要求中断服务程序尽可能地短小精悍。但是,这个良好的愿望往往与现实并不吻合。

在大多数真实的系统中,当中断到来时,要完成的工作往往并不会是短小的,它可能

要进行较大量的耗时处理。 

为了在中断执行时间尽可能短和中断处理需完成大量工作之间找到一个平衡点,Linux 将中断

处理程序分解为两个半部:顶半部(top  half)和底半部(bottom half)。 

顶半部完成尽可能少的比较紧急的功能,它往往只是简单地读取寄存器中的中断状态并清除

中断标志后就进行“登记中断”的工作。“登记中断”意味着将底半部处理程序挂到该设备的底半

部执行队列中去。这样,顶半部执行的速度就会很快,可以服务更多的中断请求。

现在,中断处理工作的重心就落在了底半部的头上,它来完成中断事件的绝大多数任务。底半部

几乎做了中断处理程序所有的事情,而且可以被新的中断打断,这也是底半部和顶半部的最大不同,

因为顶半部往往被设计成不可中断。底半部则相对来说并不是非常紧急的,而且相对比较耗时,不在

硬件中断服务程序中执行。 

尽管顶半部、底半部的结合能够改善系统的响应能力,但是,僵化地认为 Linux

设备驱动中的中断处理一定要分两个半部则是不对的。如果中断要处理的工作本身很

少,则完全可以直接在顶半部全部完成。 

其他操作系统中对中断的处理也采用了类似于Linux系统的方法,真正的硬件中断服务程序都应该尽可能短。

因此,许多操作系统都提供了中断上下文和非中断上下文相结合的机制,将中断的耗时工作保留到非中断上下文去执行。

 

Linux 系统实现底半部的机制主要有tasklet,工作队列和软中断。 

Linux 的中断处理分为两个半部,顶半部处理紧急的硬件操作,底半部处理不紧


急的耗时操作。tasklet 和工作队列都是调度中断底半部的良好机制,tasklet 基于软中


断实现。内核定时器也依靠软中断实现。


内核中的延时是忙等待或者睡眠等待,为了充分利用CPU资源,使系统有更好的


吞吐性能,在对延迟时间的要求并不是很精确的情况下,睡眠等待通常是值得推荐的。

 

http://hi.baidu.com/designhouse/item/a4bcdfc419f4ce7589ad9ed9

posted on 2014-04-03 13:10  jjssl  阅读(1413)  评论(0编辑  收藏  举报