装逼名词 bottom-half，软中断，preemptive选项

bottom-half

http://bbs.csdn.net/topics/60226240

在中断,异常和系统调用里看

Linux中断服务一般都是在关闭中断的情况下执行的,以避免嵌套而是控制复杂化
Linux将一些中断处理分成两部分,第一部分是在关中断的条件下执行的,具有"原子"性,而且是中断发生以后一般要立即执行的,第二部分,就是bottom half了,是在开中断的条件下执行,这部分是可以延迟一段时间再做的,而且有可能将多个中断的bottom half合并起来一起做.
bottom half使得整个系统灵活性提高了,因为有的中断服务持续时间很长而使CPU不能响应其他的中断而使中断丢失.

软中断

http://blog.csdn.net/sxf_824/article/details/6560363

软中断是利用硬件中断的概念，用软件方式进行模拟，实现宏观上的异步执行效果。很多情况下，软中断和"信号"有些类似，同时，软中断又是和硬中断相对应的，"硬中断是外部设备对CPU的中断"，"软中断通常是硬中断服务程序对内核的中断"，"信号则是由内核（或其他进程）对某个进程的中断"（《Linux内核源代码情景分析》第三章）。

软中断的一种典型应用就是所谓的"下半部"（bottom half），它的得名来自于将硬件中断处理分离成"上半部"和"下半部"两个阶段的机制：上半部在屏蔽中断的上下文中运行，用于完成关键性的处理动作；而下半部则相对来说并不是非常紧急的，通常还是比较耗时的，因此由系统自行安排运行时机，不在中断服务上下文中执行。bottom half的应用也是激励内核发展出目前的软中断机制的原因，因此，我们先从bottom half的实现开始。

最早的bottom half实现是借用中断向量表的方式，在目前的2.4.x内核中仍然可以看到：。。。

在介绍tasklet之前，有必要先看看出现得更早一些的task queue机制。显而易见，原始的bottom half机制有几个很大的局限，最重要的一个就是个数限制在32个以内，随着系统硬件越来越多，软中断的应用范围越来越大，这个数目显然是不够用的，而且，每个bottom half上只能挂接一个函数，也是不够用的。因此，在2.0.x内核里，已经在用task queue（任务队列）的办法对其进行了扩充，这里使用的是2.4.2中的实现。

由上看出，task queue以bottom half为基础；而bottom half在v2.4.x中则以新引入的tasklet为实现基础。
　　
　　之所以引入tasklet，最主要的考虑是为了更好的支持SMP，提高SMP多个CPU的利用率：不同的tasklet可以同时运行于不同的CPU上。在它的源码注释中还说明了几点特性，归结为一点，就是：同一个tasklet只会在一个CPU上运行。

从前面的讨论可以看出，task queue基于bottom half，bottom half基于tasklet，而tasklet则基于softirq。
　　
　　可以这么说，softirq沿用的是最早的bottom half思想，但在这个"bottom half"机制之上，已经实现了一个更加庞大和复杂的软中断子系统。

static inline void __cpu_raise_softirq(int cpu, int nr)
　　
　　这个函数用来激活软中断，实际上就是第cpu号CPU的第nr号软中断的active位置1。在do_softirq()中将判断这个active位。tasklet_schedule()和tasklet_hi_schedule()都会调用这个函数。

百科上的内容：

软中断是linux系统原“底半处理”的升级，在原有的基础上发展的新的处理方式，以适应多cpu 、多线程的软中断处理。

软中断是实现系统API函数调用的手段：

函数调用时将返回地址和CPU状态寄存器内容压栈，函数执行完毕后出栈返回断点继续执行。

软中断调用时将返回地址和CPU状态寄存器内容压栈，修改特权级，根据中断号查找中断向量表，找到ISR（Interrupt Service Routine）中断服务例程地址，跳转执行。

综上，函数调用和软中断调用的区别是，软中断多了修改特权级和查找中断向量表的功能，其他部分完全一样。

一般来说，软中断是由内核机制的触发事件引起的（例如进程运行超时），但是不可忽视有大量的软中断也是由于和硬件有关的中断引起的，例如当打印机端口产生一个硬件中断时，会通知和硬件相关的硬中断，硬中断就会产生一个软中断并送到操作系统内核里，这样内核就会根据这个软中断唤醒睡眠在打印机任务队列中的处理进程。

核心元素

构成软中断机制的核心元素包括：

1、软中断状态寄存器soft interrupt state（irq_stat）

2、软中断向量表（softirq_vec）

3、软中断守护daemon

软中断的工作工程模拟了实际的中断处理过程，当某一软中断事件发生后，首先需要设置对应的中断标记位，触发中断事务，然后唤醒守护线程去检测中断状态寄存器，如果通过查询发现有软中断事务发生，那么通过查询软中断向量表调用相应的软中断服务程序action（）。这就是软中断的过程，与硬件中断唯一不同的地方是从中断标记到中断服务程序的映射过程。在CPU的硬件中断发生之后，CPU需要将硬件中断请求通过向量表映射成具体的服务程序，这个过程是硬件自动完成的，但是软中断不是，其需要守护线程去实现这一过程，这也就是软件模拟的中断，故称之为软中断。

一个软中断不会去抢占另一个软中断，只有硬件中断才可以抢占软中断，所以硬中断能够保证对时间的严格要求。

软中断的起源

http://blog.chinaunix.net/uid-27717694-id-3807979.html

Linux的这种Bottom Half（以下简称BH）机制有两个缺点，也即：
（1）在任意一时刻，系统只能有一个CPU可以执行Bottom Half代码，以防止两个或多个CPU同时来执行Bottom Half函数而相互干扰。因此BH代码的执行是严格“串行化”的。
（2）BH函数不允许嵌套。

这两个缺点在单CPU系统中是无关紧要的，但在SMP系统中却是非常致命的。因为BH机制的严格串行化执行显然没有充分利用SMP系统的多CPU特点。为此，Linux2.4内核在BH机制的基础上进行了扩展，这就是所谓的“软中断请求”（softirq）（irq:interrupt request 中断请求）机制。

2.Linux 的softirq机制是与SMP紧密不可分的。为此，整个softirq机制的设计与实现中自始自终都贯彻了一个思想：“谁触发，谁执行”（Who marks，Who runs），也即触发软中断的那个CPU负责执行它所触发的软中断，而且每个CPU都由它自己的软中断触发与控制机制。这个设计思想也使得softirq 机制充分利用了SMP系统的性能和特点。

在这里系统一共定义了32个软中断请求描述符。软中断向量i（0≤i≤31）所对应的软中断请求描述符就是softirq_vec［i］（上面说了，数量不够，现在用taskqueue了）。这个数组是个系统全局数组，也即它被所有的CPU所共享。这里需要注意的一点是：每个CPU虽然都由它自己的触发和控制机制，并且只执行他自己所触发的软中断请求，但是各个CPU所执行的软中断服务例程却是相同的，也即都是执行softirq_vec［］数组中定义的软中断服务函数。

3.要实现“谁触发，谁执行”的思想，就必须为每个CPU都定义它自己的触发和控制变量。为此，Linux在include/asm-i386/hardirq.h头文件中定义了数据结构irq_cpustat_t来描述一个CPU的中断统计信息，其中就有用于触发和控制软中断的成员变量。数据结构irq_cpustat_t 的定义如下。。。