中断上下文可为和不可为事项

转自：http://www.360doc.com/content/11/1014/00/1317564_156004641.shtml

1. 如果你的中断上下文进入睡眠，它是一项应该被处以监禁的罪行。中断处理函数不能通过调用schedule_timeout()等睡眠函数放弃处理器，在中断处理函数中调用一个内核API之前，应该仔细分析它以确保其内部不会触发阻塞等待。例如，input_register_device()表面上看起来没有问题，但是它内部以GFP_KERNEL为参数调用了kmalloc()。从第2章《内核一瞥》可以看出，用这种方式调用kmalloc()的话，如果系统的空闲内存低于某门限，kmalloc()将睡眠等待swapper释放内存。

2. 为了在中断处理函数中保护临界区，你不能使用互斥体，因为它们也许导致睡眠。应该使用自旋锁代替互斥体，但是一定要记住的是只有真正需要的时候才采用它。

3. 中断处理函数不能与用户空间直接交互数据，因为它们经由进程上下文与用户空间建立连接。这也是为什么中断处理函数不能睡眠的第2个理由：调度器工作于进程之间，如果中断处理函数睡眠并被调度出去，它们怎么返回到运行队列呢？

4. 中断处理函数一方面需要快速地出来，另一方面又需要完成它的工作。为了规避这种冲突，中断处理函数通常被分成2个部分。瘦小的顶半部标志一个响应以宣称它已经服务了该中断，而重大的工作负载都被丢给了肥胖的底半部。底半部的执行被延后，在其执行环境中，所有的中断都是使能的。在讨论softirq和tasklet的时候，你将学习到真也难怪开发底半部。

5. 中断处理函数不必是可重用的。当某中断被执行的时候，在它返回之前，相应的IRQ都被禁止了。因此，与进程上下文代码不同的是，同一中断处理函数的不同实例不可能同时运行在多个处理器上。

6. 中断处理函数可以被更高优先级IRQ的中断处理函数打断。如果你请求内核将你的中断处理函数作为快中断处理的话，此类中断嵌套将被禁止。快中断服务函数运行的时候，本处理器上的所有中断都会被禁止。在禁止中断或将你的中断标识为快中断之前，请意识到中断屏蔽对系统性能的坏处。中断屏蔽的时间越长，中断延迟就会更长，或者说已经被产生的中断得到服务的延迟就会越久。中断延迟与系统真实的响应时间成反比。