这里就行了很深入的讨论，值得一看：
但是，他们的讨论最后没有得出一个明确的结论。其中，cskyrain在8楼 的思考触及到了一个要点，但是没有深入展开：
- 1楼 发表于 2009-11-24 20:36 | 只看该作者
- 一直认为中断处理函数不能休眠的是天经地义的，可从没认真思考过问什么不能休眠，阻塞。最近看了一下ulk中对这个的解释，感觉还是有点不太明白，
- “The price to pay for allowing nested kernel control paths is that an interrupt handler must never block, that is, no process switch can take place until an interrupt handler is running. In fact, all the data needed to resume a nested kernel control path is stored in the Kernel Mode stack, which is tightly bound to the current process.”
- 上面把中断处理程序不能休眠归结为中断处理程序可以嵌套，而恢复嵌套的中断处理程序的相关数据放在内核态堆栈中，这个栈和当前进程相关联，这里有一点不明白，既然有栈存储数据，而且进程切换出去后，这个栈也不会被销毁，等进程在切回来时，不同样可以是嵌套的中断处理程序返回吗？（这里先不考了中断处理时间的太长，影响对中断处理的服务问题，只说明中断是否可休眠）。同时我google一下，看到有人对中断不能休眠的以一种解释：
- ”
- 中断处理程序用到的所有数据有保存在当前进程的内核堆栈中（一般情况下），如果此时发生了
- 进程切换，中断处理程序将被阻塞， 当在一次发生进程切换时，不一定马上就换回来。比如当
- 发生一个键盘中断时，键盘处理程序正在进行，此时又恰好发生了进程抢占，切换到了另一个进程
- 中，假如那个进程不会引起内核的稳定，那么中断处理程序将一直阻塞，内禾根本就没法响应那个中断，
- 直到在一次发生进程切换。假设最后又切换回执行中断处理程序的那个进程中时，如果它的内核堆栈
- 受到了无意的破坏怎么办呢？那中断处理程序可能无法在继续运行下去了，此次中断服务失败。而且
- 现在的处理程序都允许中断嵌套，一个中断被阻塞，其它的都将被阻塞。所以面对错综复杂的内核逻辑，
- 最好的办法就是在中断处理程序中禁止发生进程切换，这样既提高了中断处理程序的响应速度，也增加了
- 内核的稳定性与安全性。
- “
- 我感觉他的理由有两个：一个事效率，可能影响处理速度，另一就是：如果它的内核堆栈
- 受到了无意的破坏怎么办？
- 对于第一种理由先不讨论，
- 可第二种，理由我感觉很牵强，如果栈那么容易破坏，哪我也可以说描述进程的数据结构什么的也可能被破坏，哪岂不是进程调度都是不安全的了，
- 这样按他的说法，就只有第一个效率的原因了。
- 回到ulk的解释，不知道是不是我理解的有问题，The price to pay for allowing nested kernel control paths is that an interrupt handler must never block
- 感觉他把中端不能休眠的原因都归结为可支持中断处理程序的嵌套上了。那是不是可以这样理解，如果不支持中断嵌套，中断处理程序就可以休眠了，呵呵呵，貌似这样也不对吧，
- 问题：中断处理程序不能休眠的原因究竟是什么呢？
7楼：
- kouu 发表于 2009-11-25 11:52
- 回复 #6 cskyrain 的帖子
- 中断不能block，应该特指异步中断吧。
- 看了LZ这两天的帖子，我觉得还是类似4楼的说法比较靠谱：异步中断是独立的上下文，与当前进程无关，所以不能因为中断上下文的block而将无辜的进程给block了。可能就是基于这一初衷吧~ 那些已经将中断处理程序线程化了的实时linux应该是允许中断block的。
- 而同步的中断（比如系统调用、缺页异常）是代表当前进程的，本来就是可以block的。
8楼：
- 回复 #7 kouu 的帖子
- 呵呵，又翻了翻书，思考了一下，由于时间问题，没心情再从头读ulk，只是跳着查了一下，难免会漏下很多东西，不过还是说说我的理解：
- 这里中断只代表异步中断，异常代表同步中断，这样系统调用是异常处理，不是中断处理。
- 这里异常处理是可以休眠block的，因为异常处理所需的数据是存储在异常栈中，而每个进程都有一个异常栈，所以异常处理和进程是相关联的，这样异常处理可以block，被调度出去。
- 而对于中断，分为两种情况，一种是中断使用单独的中断栈而不使用进程的内核栈的情况，这样，由于所有中断共享一个中断栈，这个中断栈不和特定进程关联，所以，这种中断时不能block的，block后他是不能再被调度。
- 第二种情况是，中断不使用单独的中断栈，而是使用当前进程的内核栈，这种情况我认为是和异常处理时一样的，这种中断时可以block的，之所以不准许中断 block不是技术上切换不回来，而是逻辑上为了提高处理的效率强制其不能block。
- 以上是我现阶段的理解，感觉，前俩个的解释应该没什么问题，但最后对不是用中断栈的中断的解释可能有错误的认识，不知kouu对这种解释有何看法？
总体上，大家得到的初步结论是：内核在中断路径内不能睡眠，不是技术上做不到，而是没有理由这么做，或者说在中断路径上睡眠不合理。一方面，外部事件导致当前进程时间片被剥夺，不合理；一方面，中断服务程序应该尽快处理完中断，保证IO吞吐率。
-------------------------------分割线----------------------------
通过阅读ULK中文版第三版164页的内容，让我对这个问题有了一个较为清晰的认识：
内核在编译的时候设置了THREAD_SIZE的值为8K的话, 那么每个进程的内核栈的大小就为8K, 此时如果发生中断时, 那么进程的寄存器等值就会保存到它的8K的内核栈中. 但是如果设置了THREAD_SIZE的大小为4K的话, 内核就会使用3种类型的内核栈, 异常栈, 硬件中断请求栈以及软中断请求栈（ When using 4K stacks, interrupts get their own stack instead of using the currently active kernel stack.）
* 异常栈：每个进程一个。
* 硬中断请求栈：每个CPU一个，每个占用一个单独的页框。do_IRQ()函数内部通过调用execute_on_irq_stack负责切换到该栈中来。
* 软中断请求栈：每个CPU一个，每个占用一个单独的页框。
关于切换到中断栈的方法，请看下面的代码：
-
-
-
-
-
- unsigned int do_IRQ(struct pt_regs *regs)
- {
- struct pt_regs *old_regs;
-
- int overflow;
- unsigned vector = ~regs->orig_ax;
- struct irq_desc *desc;
- unsigned irq;
- old_regs = set_irq_regs(regs);
- irq_enter();
- irq = __get_cpu_var(vector_irq)[vector];
- overflow = check_stack_overflow();
- desc = irq_to_desc(irq);
- if (unlikely(!desc)) {
- printk(KERN_EMERG "%s: cannot handle IRQ %d vector %#x cpu %d\n",
- __func__, irq, vector, smp_processor_id());
- BUG();
- }
- if (!execute_on_irq_stack(overflow, desc, irq)) {
- if (unlikely(overflow))
- print_stack_overflow();
- desc->handle_irq(irq, desc);
- }
- irq_exit();
- set_irq_regs(old_regs);
- return 1;
- }
- static inline int
- execute_on_irq_stack(int overflow, struct irq_desc *desc, int irq)
- {
- union irq_ctx *curctx, *irqctx;
- u32 *isp, arg1, arg2;
- curctx = (union irq_ctx *) current_thread_info();
- irqctx = hardirq_ctx[smp_processor_id()];
-
-
-
-
-
-
- if (unlikely(curctx == irqctx))
- return 0;
-
- isp = (u32 *) ((char*)irqctx + sizeof(*irqctx));
- irqctx->tinfo.task = curctx->tinfo.task;
- irqctx->tinfo.previous_esp = current_stack_pointer;
-
-
-
-
- irqctx->tinfo.preempt_count =
- (irqctx->tinfo.preempt_count & ~SOFTIRQ_MASK) |
- (curctx->tinfo.preempt_count & SOFTIRQ_MASK);
- if (unlikely(overflow))
- call_on_stack(print_stack_overflow, isp);
- asm volatile("xchgl %%ebx,%%esp \n"
- "call *%%edi \n"
- "movl %%ebx,%%esp \n"
- : "=a" (arg1), "=d" (arg2), "=b" (isp)
- : "0" (irq), "1" (desc), "2" (isp),
- "D" (desc->handle_irq)
- : "memory", "cc", "ecx");
- return 1;
- }
最后，思考一下标题中的问题：linux内核在中断路径内不能睡眠/调度的原因
Linux是以进程为调度单位的，调度器只看到进程内核栈，而看不到中断栈。在独立中断栈的模式下，如果linux内核在中断路径内发生了调度（从技术上讲，睡眠和调度是一个意思），那么linux将无法找到“回家的路”，未执行完的中断处理代码将再也无法获得执行机会。
先把中断处理流程给出来
硬中断：
对应于上图的1、2、3步骤，在这几个步骤中，所有中断是被屏蔽的，如果在这个时候睡眠了，操作系统不会收到任何中断（包括时钟中断），系统就基本处于瘫痪状态（例如调度器依赖的时钟节拍没有等等……）
软中断：
对应上图的4（当然，准确的说应该是4步骤的后面一点）。这个时候不能睡眠的关键是因为上下文。
大家知道操作系统以进程调度为单位，进程的运行在进程的上下文中，以进程描述符作为管理的数据结构。进程可以睡眠的原因是操作系统可以切换不同进程的上下文，进行调度操作，这些操作都以进程描述符为支持。
中断运行在中断上下文，没有一个所谓的中断描述符来描述它，它不是操作系统调度的单位。一旦在中断上下文中睡眠，首先无法切换上下文（因为没有中断描述符，当前上下文的状态得不到保存），其次，没有人来唤醒它，因为它不是操作系统的调度单位。
此外，中断的发生是非常非常频繁的，在一个中断睡眠期间，其它中断发生并睡眠了，那很容易就造成中断栈溢出导致系统崩溃。
如 果上述条件满足了（也就是有中断描述符，并成为调度器的调度单位，栈也不溢出了，理论上是可以做到中断睡眠的），中断是可以睡眠的，但会引起很多问题.例 如，你在时钟中断中睡眠了，那操作系统的时钟就乱了，调度器也失去了依据；例如，你在一个IPI（处理器间中断）中，其它CPU都在死循环等你答复，你确 睡眠了，那其它处理器也不工作了；例如，你在一个DMA中断中睡眠了，上面的进程还在同步的等待I/O的完成，性能就大大降低了……还可以举出很多例子。 所以，中断是一种紧急事务，需要操作系统立即处理，不是不能做到睡眠，是它没有理由睡眠。
