原帖由 思一克 于 2007-6-27 09:19 发表于 1楼
看邻居帖子，大家回答的问题不大。但也有不同的回答和解释。有点乱。
有必要讨论，得出固定的结论。
其实这只是一个设计上的问题, 而并不是强制的. 只是针对Linux内核而言, 这是规矩.
LKD2上面说, 切换出去之后, 何时才能调度回来? 就是中断回来之后可能不会回到之前所依俯的那个进程了.
中断不能睡眠的的最大好处就是可以简化内核的设计. 如果说中断随时可以睡眠的话, 那么就必须考虑很多其它方面的事情, 比如睡眠之后又出现了
同一IRQ号的中断又该怎么办, 等等.
其实, 如果自己能把握好, 中断中睡眠也是可以的. 但是必须能够保证这段代码具有足够的安全性与可靠性.
这是我的理解.
呵呵，我最喜欢这种讨论了。先来献丑了，说说我的看法。
先把中断处理流程给出来
- 1.进入中断处理程序--->2.保存关键上下文---->3.开中断（sti指令）--->4.进入中断处理程序的handler--->5.关中断（cli指令）---->6.写EOI寄存器（表示中断处理完成）---->7.开中断。
硬中断：
对应于上图的1、2、3步骤，在这几个步骤中，所有中断是被屏蔽的，如果在这个时候睡眠了，操作系统不会收到任何中断（包括时钟中断），系统就基本处于瘫痪状态（例如调度器依赖的时钟节拍没有等等……）
软中断：
对应上图的4（当然，准确的说应该是4步骤的后面一点，先把话说保险点，免得思一克又开始较真 ）。这个时候不能睡眠的关键是因为上下文。
大家知道操作系统以进程调度为单位，进程的运行在进程的上下文中，以进程描述符作为管理的数据结构。进程可以睡眠的原因是操作系统可以切换不同进程的上下文，进行调度操作，这些操作都以进程描述符为支持。
中断运行在中断上下文，没有一个所谓的中断描述符来描述它，它不是操作系统调度的单位。一旦在中断上下文中睡眠，首先无法切换上下文（因为没有中断描述符，当前上下文的状态得不到保存），其次，没有人来唤醒它，因为它不是操作系统的调度单位。
此外，中断的发生是非常非常频繁的，在一个中断睡眠期间，其它中断发生并睡眠了，那很容易就造成中断栈溢出导致系统崩溃。
如果上述条件满足了（也就是有中断描述符，并成为调度器的调度单位，栈也不溢出了，理论上是可以做到中断睡眠的），中断是可以睡眠的，但会引起很多问题.例如，你在时钟中断中睡眠了，那操作系统的时钟就乱了，调度器也了失去依据；例如，你在一个IPI（处理器间中断）中，其它CPU都在死循环等你答复，你确睡眠了，那其它处理器也不工作了；例如，你在一个DMA中断中睡眠了，上面的进程还在同步的等待I/O的完成，性能就大大降低了……还可以举出很多例子。所以，中断是一种紧急事务，需要操作系统立即处理，不是不能做到睡眠，是它没有理由睡眠。
好了，罗嗦了一大堆，大家见仁见智，不要骂人就好。
中断sleep, preempt和 实时性瓶颈介绍.
原帖由 zx_wing 于 2007-6-27 10:09 发表于 4楼
呵呵，我最喜欢这种讨论了。先来献丑了，说说我的看法。
先把中断处理流程给出来
1.进入中断处理程序--->2.保存关键上下文---->3.开中断（sti指令）--->4.进入中断处理程序的handler--->5.关中 ...
里面很多说法不是很同意, 个人认为中断处理handler不能sleep原因应该不是上面那些.
我们都是从理论讲下面这些问题, 因为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中, 引发了下面的讨论:
注意下面这段话.
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的实现.
原帖由 xiaozhaoz 于 2007-6-27 22:00 发表于 19楼
里面很多说法不是很同意, 个人认为中断处理handler不能sleep原因应该不是上面那些.
我们都是从理论讲下面这些问题, 因为linux在很多地方做了保护, 所以直接sleep或者schedule()会导致内核异常.
首先分 ...
>>这其实和"中断没有自己的上下文"无关. CPU没有关中断, 中断有自己的上下文, 中断的上下文就是抢占的任务A的上下文.
“中断没有自己的上下文”，呵呵，我没有说这句话哈。lz很多立论在这句话上，估计是看贴的时候看错了。
>>假设中断sleep了, 在调度的时候, 内核将中断的CS:eip和SS:esp保存在被抢占任务A的thread_info中, 当任务A被重新唤醒的时候, 任务A从中断的CS:eip开始执行, 这也能正常执行下去, 中断执行完后, 从ret_from_intr中返回. 可以恢复任务A的抢占前的场景.
这里在中断sleep了，由谁来唤醒呢？关键还是没有一个中断描述符来作为内核调度的单位。
前面也说到了，这是个设计问题，不是能不能实现的问题。
如果说把中断的handler作为一组内核线程，当然是可以让中断睡眠的。但我始终任为中断是紧急事务，必须立即处理，我想不出有任何理由推迟中断的处理。
原帖由 xiaozhaoz 于 2007-6-28 12:19 发表于 39楼
对, 就是这个意思,
所以这种系统的不确定性就很大.
而现在的中断除了不sleep, 不能preempt之外, 对任务的影响也想你说的那样"中奖"式的, 所以现在系统的实时性是无法保证的!!
解决这个问 ...
>>总结: 异步异常(中断)handler不是没有上下文, 而是没有固定的上下文, 如果使用被抢占的任务作为上下文, 一,自身的处理无法得到实时保障,导致系统不确定性, 二,任务受到影响.
linux是通用操作系统，并不是专门为嵌入式设计的实时操作系统，所以影响系统的实时性并不是中断不能睡眠的原因。
诚然，中断不像进程那样有固定的上下文，所以它在linux中不是调度器的调度单位，所以不能睡眠，因为睡眠、唤醒都是调度器的任务，你不被调度器调度，当然不能睡眠。如你所说，它是可以被实现成可睡眠的，但我这里讲述的是它在linux中不能睡眠的原因。如果我的理解还不对的话，请lz再用一句总结一下在linux中中断不能睡眠的原因。因为你文字比较多，我看的有点乱了。
LZ发帖子是讨论，不是有什么总结性的一句话能概括什么。我也是在学习中。
我觉得，LINUX设计不让中断中睡眠是经过充分考虑的。seelp on interrupt（SOI）不允许是内核设计的原因，而不是有什么绝对本质的无法更改的原因。
我同意zx_wing的说法，没有和进程关联的CONTEXT，而调度的基本单位是进程，因此KERNEL设计者无法容忍sleep on interrrupt(SOI).
下面的相同的讨论说的也很清楚：
think this should clear all confusions, apologies if this is too big
or irrelevant and doesnt make much sense, which I think is not the
case.
Note : The following explaination assumes that the isr and the
interrupted proceess share the stack, afaik isr can seperate stacks,
which is configurable, but I dont know how this explaination holds
good when the isr is having a seperate stack.
1. Why you are not allowed to sleep in an interrupt handler?Was this a
design decision or is there a fundamental reason that makes sleeping
interrupt handlers simply impossible? What about the page fault
handler - it (probably) sleeps when it has to swap in a page, why is
it possible to sleep for the page fault handler and not for an
interrupt handler?
-> Sleeping is implemented using scheduler. Scheduler only schedules
tasks (design decision to keep it simple). So you need a task context
to sleep in. Interrupt is not tied to a process (and uses stack of
whichever happens to be scheduled ) so it can't use the context
because it does not have to be in a sane state.
2. But why.....
You cannot sleep in an interrupt handler because interrupts do not have
a backing process context, and thus there is nothing to reschedule
back into. In other words, interrupt handlers are not associated with
a task, so there is nothing to "put to sleep" and (more importantly)
"nothing to wake up". They must run atomically.
The reason the page fault handler can sleep is that it is invoked only
by code that is running in process context. Because the kernel's own
memory is not pagable, only user-space memory accesses can result in a
page fault. Thus, only a few certain places (such as calls to
copy_{to,from}_user()) can cause a page fault within the kernel. Those
places must all be made by code that can sleep (i.e., process context,
no locks, etc).
3. However can't you consider the interrupt handler as running in the
context of the task A, that was incidentially running when the
interrupt occurred (the interrupt handler
uses the stack of task A, this is not always true, isr might have a
seperate stack). So wouldn't it conceptually be conceivable to put the
interrupt handler to sleep by saving the current CPU state (register
contents) with task A, putting task A asleep, and resume processing of
the interrupt once task A is rescheduled by the scheduler?
Of course this could be considered 'unfair' with respect to task A, in
that the interrupt has no relation to task A besides the fact that
they happend to be on the same CPU at the same time. But I am
interested in learning if there is any fundamental reason against
sleeping in an interrupt handler.
->There are bigger problems. The process is in an arbitrary state when
interrupt is invoked. So it might hold arbitrary spinlocks. It might
be on arbitrary wait_queues. Possibly other funny things might happen.
These either disallow sleeping or could interact badly with the
interrupt trying to sleep.
This is part of conversation happened on the same list before few
years, not verbatim though.
--
这里也说到了如果IRQ不用自己的STACK，而利用被中断任务（任务A）的STACK是否就可以SOI了的问题。
因为中断发生的CONTEXT和A无关，而是碰巧在同一个CPU上的一个任务A被中断了，如果中断睡了，A就回被殃及，系统就彻底乱了。
（和调度发生冲突了）。
至于schedule()会将任务在不同CPU之间分，而IRQ回来后如何？（假定IRQ不使用自己的STACK，可以回来的话）。
还有最后一段说的其他各种复杂的问题。
总之，如果中断不THREAD化，应该无法SOI。所以LINUX（2。6）中shedule()中有检查不允许。
如果改动LINUX，如何改动最小使得可以SOI？（虽然没有大意义，但作为讨论可以从讨论中学习其他的）。
原帖由 zx_wing 于 2007-6-28 12:38 发表于 40楼
>>总结: 异步异常(中断)handler不是没有上下文, 而是没有固定的上下文, 如果使用被抢占的任务作为上下文, 一,自身的处理无法得到实时保障,导致系统不确定性, 二,任务受到影响.
linux是通用操作系统 ... |
|
|
|
|
|
