中断sleep, preempt和 实时性瓶颈介绍.
QUOTE:
原帖由 xiaozhaoz 于 2007-6-27 22:36 发表于 21楼
简单看了一下前面的回复, 不能认同. 问题的焦点大家都集中在异步异常(中断)没有自己的上下文? 中断抢占了当前任务后, 可以通过current获得当前的task结构, 将当前任务的寄存器信息压入栈中, 替换成自己的eip和esp. 你完全可以理解为当前任务调用了handler()函数. 当然, 如果中断使用了自己的栈, 就会有问题!! 如果handler()函数调用了 schedule_timeout_interruptible(1000) 这样当前任务就被加入到定时器中, 定时器软中断到了1000ms就会把handler抢占的任务唤醒. 当然上述代码要正常工作, 要修改内核一些地方, 如schedule()里面的很多检查, 中断中的很多标志位和锁, entry.s中的很多判断. 只是想说明, 中断不能sleep, 不是因为没有上下文! 的确不光是上下文的问题，比如说还有调度的问题。 假设按你说的方式中断睡眠后，被打断线程也跟着睡眠显然会导致很多不可预知的问题。 中断产生是随机的，假设某次中断一个内核线程，而且按照你说的方案，这个线程的task结构就会被借用，线程就会去睡眠。被打断线程的优先级如果太低，那么它很难有机会再执行，某些情况下可能造成系统hang。如果临时提高被打断线程的优先级，那么又需要设计新的唤醒机制来保证阻塞同一锁上的高优先级的线程被先唤醒。同时，要实现临时提高被打断线程的优先级，又需要再锁的获取流程增加改变优先级的算法。 总之，没有考虑的问题还很多。 QUOTE:
原帖由 Solaris12 于 2007-6-27 23:05 发表于 22楼
的确不光是上下文的问题，比如说还有调度的问题。 假设按你说的方式中断睡眠后，被打断线程也跟着睡眠显然会导致很多不可预知的问题。 中断产生是随机的，假设某次中断一个内核线程，而且按照你说的 ... 所见略同.  19楼描述的就是这个问题. 而realtime Patch解决的也是这个问题. PS. 最近在做一个多内核的项目, 包括solaris, 请问你们讨论solaris内核一般在哪里? OpenSolaris的mail list感觉不太热闹. QUOTE:
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 2。6 内核中断（软中断）自己使用自己的堆栈。
LINUX调度的单位是进程，中断中睡眠后因没有CONTEXT回不来。 还有2楼说的我同意，在中断中不让调度主要是设计问题。所以就LINUX具体看。 如果一定要改动系统，设计的中断可以调度，是可以办到的。 QUOTE:
原帖由 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作为一组内核线程，当然是可以让中断睡眠的。但我始终任为中断是紧急事务，必须立即处理，我想不出有任何理由推迟中断的处理。 QUOTE:
原帖由 Solaris12 于 2007-6-27 20:25 发表于 17楼
Cool! 你说的很准确。的确是你说的情况。 举例来说， 写网卡驱动程序，我们通常把中断服务函数说成ISR。 但在Solaris里，每个级低优先级中断都有个IST,中断服务线程。 我说的ISR是驱动程序的 ... 看来Solaris中的IST有点类似用内核线程来实现中断的handler，这种情况下应该是可以睡眠的。 Solaris的实现果然和linux有很多不同，要多多请教了。 QUOTE:
原帖由 xiaozhaoz 于 2007-6-27 22:36 发表于 21楼
简单看了一下前面的回复, 不能认同. 问题的焦点大家都集中在异步异常(中断)没有自己的上下文? 中断抢占了当前任务后, 可以通过current获得当前的task结构, 将当前任务的寄存器信息压入栈中, 替换成自 ... 此外，我想lz对上下文一词还有点误解。 上下文（context）表示当前cpu的状态，包括各种标志及寄存器的值。这里中断是运行在自己的上下文而不是进程的上下文。如果是运行在进程上下文的话，中断处理就不需要在开始就保存上下文，在离开的时候又恢复。 当然，有一些先进的处理器（例如安腾），它为中断处理程序提供了一套专门的寄存器供中断处理程序使用，这个时候很多上下文是不需要保存的（但并非说就不保存上下文，只是某些不用保存） 中断当然有自己的CONTEXT。但没有（准确说经常没有）进程相关的CONTEXT。
你看2.6.13 KERNEL，IRQ使用 自己的STACK，如果在中断中schedule()了，能正确回来吗？ QUOTE:
原帖由 zx_wing 于 2007-6-28 10:56 发表于 29楼
此外，我想lz对上下文一词还有点误解。 上下文（context）表示当前cpu的状态，包括各种标志及寄存器的值。这里中断是运行在自己的上下文而不是进程的上下文。如果是运行在进程上下文的话，中断处理就不需要在 ... QUOTE:
原帖由 zx_wing 于 2007-6-28 10:37 发表于 27楼
>>这其实和"中断没有自己的上下文"无关. CPU没有关中断, 中断有自己的上下文, 中断的上下文就是抢占的任务A的上下文. “中断没有自己的上下文”，呵呵，我没有说这句话哈。lz很多立论在这 ... 中断sleep了, 由谁来唤醒? 在关中断的情况下, 不能sleep, 19楼已经描述了. 在中断handler中, 绝大部分都是开中断的, 这个时候为什么不能sleep? 时钟中断可以正常触发, 要不中断嵌套怎么实现? 当然由时钟中断的软中断来唤醒. 如我说到的: 如果内核修改好了, handler中调用schedule_timeout_interrupt().的情况. 中断都很紧急, 这不一定正确, 不是所有的中断handler都紧急, 就如solaris中描述的, 时钟中断最紧急, 其他的中断不一定. 可能有的实时任务比中断紧急. 中断没有上下文确实不是你说的, sorry. QUOTE:
原帖由 思一克 于 2007-6-28 11:05 发表于 31楼
中断当然有自己的CONTEXT。但没有（准确说经常没有）进程相关的CONTEXT。 你看2.6.13 KERNEL，IRQ使用 自己的STACK，如果在中断中schedule()了，能正确回来吗？ 不好意思，我看贴也不仔细，把lz“总结: 异步异常(中断)handler不是没有上下文, 而是没有固定的上下文, 如果使用被抢占的任务作为上下文, 一,自身的处理无法得到实时保障,导致系统不确定性, 二,任务受到影响.”这句话看成中断使用进程上下文了。  QUOTE:
原帖由 思一克 于 2007-6-28 11:05 发表于 31楼
中断当然有自己的CONTEXT。但没有（准确说经常没有）进程相关的CONTEXT。 你看2.6.13 KERNEL，IRQ使用 自己的STACK，如果在中断中schedule()了，能正确回来吗？ 你再编译的时候, 把4K的stack的选项不要选上, 中断和软中断就不会使用自己的栈, 而是使用被抢占任务的栈了. 所以栈不是中断不能sleep的原因. QUOTE:
原帖由 xiaozhaoz 于 2007-6-28 11:13 发表于 32楼
中断sleep了, 由谁来唤醒? 在关中断的情况下, 不能sleep, 19楼已经描述了. 在中断handler中, 绝大部分都是开中断的, 这个时候为什么不能sleep? 时钟中断可以正常触发, 要不中断嵌套怎么实现? 当然由时钟中 ... >>在中断handler中, 绝大部分都是开中断的, 这个时候为什么不能sleep? 时钟中断可以正常触发, 要不中断嵌套怎么实现? 当然由时钟中断的软中断来唤醒. 如我说到的: 如果内核修改好了, handler中调用schedule_timeout_interrupt().的情况. 当然，如果你把handler用内核进程来实现，当然是可以睡眠和被调度的。这只是个实现问题。我这里的指的是linux下不能睡眠的原因。 >>中断都很紧急, 这不一定正确, 紧急是个相对概念，我认为中断都比进程紧急 QUOTE:
原帖由 zx_wing 于 2007-6-28 10:56 发表于 29楼
此外，我想lz对上下文一词还有点误解。 上下文（context）表示当前cpu的状态，包括各种标志及寄存器的值。这里中断是运行在自己的上下文而不是进程的上下文。如果是运行在进程上下文的话，中断处理就不需要在 ... nod, 在书里都是这样写的, 但是实际情况下比这个要复杂, 内核中光有上下文无法完成调度切换的工作, 所以在Linux Kernel中, 我一般将上下文指作可以协助Kernel完成调度的东西, 就是内核task, thread_info结构, + CPU寄存器. QUOTE:
原帖由 zx_wing 于 2007-6-28 11:25 发表于 35楼
>>在中断handler中, 绝大部分都是开中断的, 这个时候为什么不能sleep? 时钟中断可以正常触发, 要不中断嵌套怎么实现? 当然由时钟中断的软中断来唤醒. 如我说到的: 如果内核修改好了, handler中调用sch ... 我想你还没有真正理解我的意思, 19楼的总结说得很清楚, 中断handler不能sleep, 不是因为没有"我说的上下文", 而是因为没有固定的上下文, 他会随机抢占当前任务, 使用当前任务的上下文作为调度单元. 既然有了调度单元, 他为什么不能sleep? solaris12和我的想法差不多, 真正愿意那是调度问题和系统问题. 怎么解决这些问题, 就是19楼介绍的内核实时性瓶颈的问题. 在中断跟内核用的是同一个栈的情况下，如果系统允许某个handler中可以sleep，那么在不可预知的任何时候，任何一个内核线程/进程在执行的时候，恰好来了上面的中断并执行到了handler，则这个内核线程/进程就"中奖"了，就会sleep，而只要这个handler是在开中的情况下运行的，它是可以被其他线程/进程唤醒的，关键是系统中所有的线程/进程都有这个"中奖"机会，哈哈
这样理解对吗？ QUOTE:
原帖由 augustusqing 于 2007-6-28 11:41 发表于 38楼
在中断跟内核用的是同一个栈的情况下，如果系统允许某个handler中可以sleep，那么在不可预知的任何时候，任何一个内核线程/进程在执行的时候，恰好来了上面的中断并执行到了handler，则这个内核线程/进程就&quo ... 对, 就是这个意思, 所以这种系统的不确定性就很大. 而现在的中断除了不sleep, 不能preempt之外, 对任务的影响也想你说的那样"中奖"式的, 所以现在系统的实时性是无法保证的!! 解决这个问题的方法就是让handler只能在固定的上下文中sleep, 当然能不sleep最好不要sleep. 所以就有了将handler放到专门内核线程中处理的想法. 如果内核的实时性足够好, 那么handler线程的执行也可以得到保证. QUOTE:
原帖由 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？（虽然没有大意义，但作为讨论可以从讨论中学习其他的）。 QUOTE:
原帖由 zx_wing 于 2007-6-28 12:38 发表于 40楼
>>总结: 异步异常(中断)handler不是没有上下文, 而是没有固定的上下文, 如果使用被抢占的任务作为上下文, 一,自身的处理无法得到实时保障,导致系统不确定性, 二,任务受到影响. linux是通用操作系统 ... QUOTE:
原帖由 思一克 于 2007-6-28 13:16 发表于 41楼
LZ发帖子是讨论，不是有什么总结性的一句话能概括什么。我也是在学习中。 我觉得，LINUX设计不让中断中睡眠是经过充分考虑的。seelp on interrupt（SOI）不允许是内核设计的原因，而不是有什么绝对本质的无法 ... 我说的lz是xiaozhaoz兄，因为他概括的观点有点多，我看的不是很明白，所以想让他总结一下。 呵呵，版主以为我在叫你啦 QUOTE:
原帖由 zx_wing 于 2007-6-28 13:59 发表于 42楼
我说的lz是xiaozhaoz兄，因为他概括的观点有点多，我看的不是很明白，所以想让他总结一下。 呵呵，版主以为我在叫你啦  我个人的看法, 相信大家会有更多的想法. 一句话的总结: 中断sleep会导致系统工作异常. 三句话总结: 1. 中断sleep会增加 任务, 系统的不确定性 2. 和中断共享中断号的中断会受到影响. 3. 中断的处理受到被抢占任务上下文属性的限制. 解释和解决的方法看19楼. 总之, 我们都是在玩文字游戏, 中断没有固定上下文(context), 而不是没有上下文. PS, 正是因为Linux是一个通用的操作系统, 所以必须让用户可以配置成嵌入式实时模式, 所以必须考虑实时性因素! 我看了19楼的帖子，
觉得 中断和软中断的线程化和spin_lock的可sleep化这两个并不能提高系统的实时性。 比如spinlock, 就是为了短暂需要lock的时候让CPU空等待。这时比用可以sleep的锁要节省CPU而不是浪费。因为调度的耗费可能要比SPIN的耗费多的多。 linux的中断是半THREAD化的。你可以增加工作在THREAD（softirqd)中的比重，增加后，系统反映更慢了。比如你打一个字，一个网络包的处理，如果都用THREAD做，响应应该是慢一些。因为调度的原因 。 如果不对，请批驳。 QUOTE:
原帖由 思一克 于 2007-6-28 14:51 发表于 46楼
我看了19楼的帖子， 觉得 中断和软中断的线程化和spin_lock的可sleep化这两个并不能提高系统的实时性。 比如spinlock, 就是为了短暂需要lock的时候让CPU空等待。这时比用可以sleep的锁要节省CPU而不是浪 ... 好几个同事问过同样的问题. 这个问题已经脱离了本贴的原意, 如果有兴趣, 可以另外开贴讨论. 实时性的必须保证, 系统在任何情况下, 可以在一定的时间内执行到某个任务. 1. 你的比较尺度有问题, 你是拿现有系统的最好情况和realtime patch系统的最坏情况比较. 2. 现有系统的最坏情况, 延时可能有几十毫秒, 察看19楼的描述. 而realtime patch的系统只有几十us(不要低估了我们CPU的处理能力  , 而且上限制是可以计算的.具体你可以在网上找到大量的测试报告.
中断本来就是用来处理紧急/突发事件的, 而进程睡眠是因为没有事情可以做才去睡眠的,
两者本来就属于对立的情形. 所以,为什么要让中断处理程序去睡眠呢? 看了半天，头都大了。这问题看一下操作系统的原理或设计类书就明白了。
1.中断是可以睡眠的；如果你要这样设计的话； 传统UNIX： 2.中断是没有必要睡眠的，因为它和所有进程无关（事实上也有关，不然什么地方来的中断，比如磁盘中断总是和哪个读写磁盘的进程有关的 ）3.更重要的是，它能很快完成，不睡眠被认为能“充分利用资源”； 实时系统: 4.在实时系统中，中断应当被设计成能够睡眠，并被高优先级的进程抢占； 5.中断优先级，是指2.中的相关进程的优先级；保存上下文不是问题，你可以将其设计成中断任务（或线程）; 6.555，很难实现. QUOTE:
原帖由 albcamus 于 2007-6-28 14:30 发表
 我怎么觉得你们3位彼此都懂对方说什么，只不过主张不同？ 有点像FREE BSD,LINUX,OPEN SOLARIS之间的关系。。。。 我觉得linux在将来的版本会实现kthread并把interrupt routine也归入其中。 就像solaris。在进程和进程调度方面，solaris确实是走在前面。 并不是说把中断以kthread形势呈现就是为了调度它，而是在内核真正抽象出thread概念。 QUOTE:
原帖由 scutan 于 2007-6-27 09:38 发表
其实这只是一个设计上的问题, 而并不是强制的. 只是针对Linux内核而言, 这是规矩. LKD2上面说, 切换出去之后, 何时才能调度回来? 就是中断回来之后可能不会回到之前所依俯的那个进程了. 中断不能睡眠 ... 睡眠是进程调度的概念,中断若睡眠上下文保持[进程的概念]与中断的概念冲突.要讨论为何要睡眠?软中断中也不需要睡眠,可用不同分支处理不同情况,没有睡眠的必要.完全可用网络中CPU上下文保留一些缓冲等与睡眠有些类似. |
|
|
来自： astrotycoon > 《kernel》
