linux中断处理原理分析

作者：时间：2016-12-09来源：网络收藏

　　Tasklet作为一种新机制，显然可以承担更多的优点。正好这时候SMP越来越火了，因此又在tasklet中加入了SMP机制，保证同种中断只能在一个cpu上执行。在软中断时代，显然没有这种考虑。因此同一种中断可以在两个cpu上同时执行，很可能造成冲突。

本文引用地址：http://www.eepw.com.cn/article/201612/341381.htm

　　Linux中断下半部处理有三种方式：软中断、tasklet、工作队列。

　　曾经有人问我为什么要分这几种，该怎么用。当时用书上的东西蒙混了过去，但是自己明白自己实际上是不懂的。最近有时间了，于是试着整理一下linux的中断处理机制，目的是起码从原理上能够说得通。

　　一、最简单的中断机制

　　最简单的中断机制就是像芯片手册上讲的那样，在中断向量表中填入跳转到对应处理函数的指令，然后在处理函数中实现需要的功能。类似下图：

　　这种方式在原来的单片机课程中常常用到，一些简单的单片机系统也是这样用。

　　它的好处很明显，简单，直接。

　　二、下半部

　　中断处理函数所作的第一件事情是什么?答案是屏蔽中断(或者是什么都不做，因为常常是如果不清除IF位，就等于屏蔽中断了)，当然只屏蔽同一种中断。之所以要屏蔽中断，是因为新的中断会再次调用中断处理函数，导致原来中断处理现场的破坏。即，破坏了 interrupt context。

　　随着系统的不断复杂，中断处理函数要做的事情也越来越多，多到都来不及接收新的中断了。于是发生了中断丢失，这显然不行，于是产生了新的机制：分离中断接收与中断处理过程。中断接收在屏蔽中断的情况下完成;中断处理在时能中断的情况下完成，这部分被称为中断下半部。

　　从上图中看，只看int0的处理。Func0为中断接收函数。中断只能简单的触发func0，而func0则能做更多的事情，它与funcA之间可以使用队列等缓存机制。当又有中断发生时，func0被触发，然后发送一个中断请求到缓存队列，然后让funcA去处理。

　　由于func0做的事情是很简单的，所以不会影响int0的再次接收。而且在func0返回时就会使能int0，因此funcA执行时间再长也不会影响int0的接收。

　　三、软中断

　　下面看看linux中断处理。作为一个操作系统显然不能任由每个中断都各自为政，统一管理是必须的。

　　我们不可中断部分的共同部分放在函数do_IRQ中，需要添加中断处理函数时，通过request_irq实现。下半部放在do_softirq中，也就是软中断，通过open_softirq添加对应的处理函数。

　　四、tasklet

　　旧事物跟不上历史的发展时，总会有新事物出现。

　　随着中断数的不停增加，软中断不够用了，于是下半部又做了进化。

　　软中断用轮询的方式处理。假如正好是最后一种中断，则必须循环完所有的中断类型，才能最终执行对应的处理函数。显然当年开发人员为了保证轮询的效率，于是限制中断个数为32个。

　　为了提高中断处理数量，顺道改进处理效率，于是产生了tasklet机制。

　　Tasklet采用无差别的队列机制，有中断时才执行，免去了循环查表之苦。

　　总结下tasklet的优点：

　　(1)无类型数量限制;

　　(2)效率高，无需循环查表;

　　(3)支持SMP机制;

　　五、工作队列

　　前面的机制不论如何折腾，有一点是不会变的。它们都在中断上下文中。什么意思?说明它们不可挂起。而且由于是串行执行，因此只要有一个处理时间较长，则会导致其他中断响应的延迟。为了完成这些不可能完成的任务，于是出现了工作队列。工作队列说白了就是一组内核线程，作为中断守护线程来使用。多个中断可以放在一个线程中，也可以每个中断分配一个线程。

　　工作队列对线程作了封装，使用起来更方便。

　　因为工作队列是线程，所以我们可以使用所有可以在线程中使用的方法。