中断里为什么不能睡眠
前几天被人问到了“中断里为什么不能睡眠”这个问题，之前我并没有深究过这个问题。后来查了一下资料，基本上所有的论坛和博客都说：因为中断没有上下文，如果睡眠被切换出去之后就无法再切回来。我实在是不能认同这种说法，中断确实没有自己的上下文，但是中断发生的时候它使用的是被中断进程的上下文，如果真的让中断睡眠的话在switch_to函数里会把当前中断的cs:eip保存到被中断进程的thread里，所以在一些特殊情况下中断是能切回来的。
我比较认同http://bbs.chinaunix.net/thread-2115820-2-1.html这里19楼的说法。把它贴出来：
我们都是从理论讲下面这些问题, 因为linux在很多地方做了保护, 所以直接sleep或者schedule()会导致内核异常.
首先分清楚, 我们讨论的是不能sleep, 而不是不能preempt.
1. 毫无疑问, 在关中断的时候不能sleep, 这点大家都知道, 因为时钟中断无法触发. 但不是所有情况下, 在关中断时sleep都会导致系统死掉, 在SMP的情况下, 可能系统不会死掉.
2. 中断的handler能否sleep?
这其实和"中断没有自己的上下文"无关. CPU没有关中断, 中断有自己的上下文, 中断的上下文就是抢占的任务A的上下文.
和栈溢出也没有关系, 现在的中断都是可以嵌套的, 如果中断sleep只会让后面的中断抢占其他任务, 根本不存在栈溢出问题, 不过现在内核的4K中断单独栈会有问题. 这会导致栈被破坏.
假设中断sleep了, 在调度的时候, 内核将中断的CS:eip和SS:esp保存在被抢占任务A的thread_info中,
当任务A被重新唤醒的时候, 任务A从中断的CS:eip开始执行, 这也能正常执行下去, 中断执行完后, 从ret_from_intr中返回.
可以恢复任务A的抢占前的场景.
Linux内核要实现成这样, 必须解决下面问题:
中断sleep会增加普通任务的不确定性, 普通任务执行的时间, 实时性都得不到保障.
和中断共享中断号的中断会受到影响, 现在的内核设置了INPROGRESS标志.
中断因为借用了被抢占任务的上下文, 所以中断的处理受到任务上下文属性的限制.
等等很多其他问题, 总之, 中断sleep会导致被抢占任务的不确定性, 并可能导致其他中断受影响.
总结:
异步异常(中断)handler不是没有上下文, 而是没有固定的上下文, 如果使用被抢占的任务作为上下文, 一,自身的处理无法得到实时保障,导致系统不确定性, 二,任务受到影响.
如何解决:
给中断handler提供固定的内核线程上下文!!
这样, 中断不能sleep, 但中断的handler可以sleep!
为每个中断号创建一个内核任务, 中断入口函数do_irq只是唤醒相应的中断任务, 中断任务去执行相应的handler.
好处:
提高了系统的实时性. 后面可以详细讲.
坏处:
降低了中断, 软中断的实时性, 所以不是所有的中断handler都可以在固定内核任务上下文中处理. 一般来说, 时钟中断必须保证其实时性, 所以留在中断上下文中.
- 介绍: Linux系统的实时性瓶颈在哪里??
- 一个实时性系统, 必须保证: 系统中优先级高的任务, 被唤醒后, 在很小的可控的延时内, CS:eip指令得到执行.
- 一个好的实时性系统, 必须保证: 系统中的所有等待运行的任务, 可以在一个固定的可接受的延时内, CS:eip指令得到执行.
- 这些延时包括 中断响应延时, 中断处理延时, 调度响应和调度处理延时.
试想现有的系统, 一个任务可能在以下上下文中被唤醒:
1. 中断上下文, 如dma数据传输完成等等设备驱动.
中断上下文唤醒任务后, 任务被加入到running队列, 返回, 继续执行中断, 中断执行完成后, 执行软中断,
中间可能会出现中断嵌套. 直到最后ret_from_intr, 才会判断是否需要抢占当前任务. 然后调用schedule().
从队列被加入running队列到schedule()函数真正开始执行, 这段时间是中断处理延时+调度响应延时.
如何缩短这部分延时和我们前面讨论的东西很有关.
正是因为中断,软中断不能preempt, 不能sleep, 导致了系统的实时性变差. 而在这些时间中, 中断handler和软中断handler消耗绝大部分时间.
设想一下, 如果中断handler和软中断handler放在专门的内核任务中执行, 中断handler中唤醒任务A,
wakeup中通过优先级判断handler任务是否需要被任务A抢占, 如果需要, 设置handler任务的NEED_RESCHEDULE标志,
调用resched_task()可以马上进入schedule(), 其中的延时非常小, 而且非常稳定. 当然, 可能wakeup后,
立即有中断到来, 但因为中断执行路径变得非常短, 只是唤醒响应的handler任务, 可能只需要100行以内的代码.所以这些时间可以忽略不计.
这种做法可以极大提高系统的实时性.
2. 软中断上下文: 如定时器到期, 目的地是本地的报文送到socket层. 等等
软中断的情况和中断类似, 可以通过将软中断线程化, 提高系统实时性.
3. 普通任务上下文, 如任务间通信等等.
普通任务一旦在内核中执行了spin_lock(), 其他任务无法抢占这个CPU, 即使另外优先级高的任务不和它共享资源,
也无法及时得到调度. 当CPU变多, 内核代码变大的时候, 这个问题也变得非常突出, 所以spin_lock()也是一个影响系统实时性的设计.
如果将spin_lock变成可以抢占的锁, 会是怎样? 如果spin_lock可以抢占, 一旦任务B抢占了任务A,
而任务A执行了spin_lock(xxx), 恰好任务B也执行spin_lock(xxx), 必然导致内核死锁.
如果spin_lock()可以抢占, 且可以sleep(), 结果又会怎样. 任务B执行spin_lock(xxx)必然导致自己sleep,
这时任务A可以接着执行spin_unlock(xxx),唤醒任务B. 这时又有一个优先级反转问题需要解决, 假设任务B的优先级最高,
任务A最低, 任务C中等, B因为拿不到xxx锁而sleep, 重新调度, 结果调度到任务C执行, 任务B因此丧失了优先级优势,
这种情况在嵌入式系统中可能会导致很严重的问题. 所以任务A必须继承任务B的优先级, 重新调度的时候才能调度到任务A先运行.
--------------------------------------------------------------------------------------
上面这些系统问题的改正可以提高系统的实时性, 但整个内核的编程模型会变得更复杂. 这些东西就是Ingo Molnar在2005年实现的Realtime Patch中的核心思想, 但在2006年的Kernel Summit中, 引发了下面的讨论:
http://lwn.net/Articles/191782/
注意下面这段话.
The question was asked: why bother with sleeping locks? Making locks
preemptible is seen by some as a way of papering over the real problem:
long lock hold times. Why not simply fix those? The answer comes in a
couple of parts:
* Extensive efforts have been expended toward fixing lock problems
for many years, and those efforts will continue into the future. The use
of sleeping locks is not being used as an excuse to avoid fixing code
which holds locks for too long.
* Ensuring realtime response in the absence of preemptible locks
requires auditing the entire body of kernel source - all eight million
lines or so. That's a big job, and one which is hard to keep up with in
an environment where nearly ten thousand lines of code are being changed
every day. Sleeping locks reduce the audit requirements to a couple
thousand lines - a much more tractable problem. For those who need
realtime response, guaranteed, that is a good deal.
因为众多的争议, 中断和软中断的线程化和spin_lock的可sleep化没有合入主流内核中.
如果realtime patch合并到主流内核中, 可以满足: 系统中优先级高的任务, 被唤醒后, 在很小的可控的延时内, CS:eip指令得到执行.
但不能保证低优先级的时延, 这正是CFS要解决的问题, 设想一下, 要让系统中的任何优先级的任务在一定的时间内得到执行, 必然要求等待时间长的任务优先得到执行, CFS就是用等待时间来作为调度的依据, 而优先级居次. 有时间在讨论CFS的实现.
