为什么在中断上下文中执行的内核代码/线程无法休眠? [英] Why kernel code/thread executing in interrupt context cannot sleep?

问题描述

我正在阅读罗伯特·洛夫(Robert Love)的下一篇文章

I am reading following article by Robert Love

http://www.linuxjournal.com/article/6916

说

"......让我们讨论一个事实，即工作队列在进程上下文中运行.这与其他下半机制相反，后者都在中断上下文中运行.在中断上下文中运行的代码无法休眠或阻塞，因为中断上下文没有可用于重新调度的后备进程，因此，由于中断处理程序与进程没有关联，因此调度程序无需进入睡眠状态，更重要的是，调度程序无需唤醒. .."

"...Let's discuss the fact that work queues run in process context. This is in contrast to the other bottom-half mechanisms, which all run in interrupt context. Code running in interrupt context is unable to sleep, or block, because interrupt context does not have a backing process with which to reschedule. Therefore, because interrupt handlers are not associated with a process, there is nothing for the scheduler to put to sleep and, more importantly, nothing for the scheduler to wake up..."

我不明白. AFAIK，内核中的调度程序是O(1)，它是通过位图实现的.那么，是什么阻止了scehduler将中断上下文置于睡眠状态并接受下一个可调度进程并将其传递给控件呢?

I don't get it. AFAIK, scheduler in the kernel is O(1), that is implemented through the bitmap. So what stops the scehduler from putting interrupt context to sleep and taking next schedulable process and passing it the control?

推荐答案

我认为这是一个设计思路.

I think it's a design idea.

当然，您可以设计一个可以在中断中进入睡眠状态的系统，但是除了使该系统难以理解和变得复杂之外(必须考虑许多情况)，这无济于事.因此，从设计的角度来看，将中断处理程序声明为无法进入睡眠"非常清晰且易于实现.

Sure, you can design a system that you can sleep in interrupt, but except to make to the system hard to comprehend and complicated(many many situation you have to take into account), that's does not help anything. So from a design view, declare interrupt handler as can not sleep is very clear and easy to implement.

来自Robert Love(内核黑客): http://permalink.gmane.org/gmane.linux.kernel.kernelnewbies/1791

From Robert Love (a kernel hacker): http://permalink.gmane.org/gmane.linux.kernel.kernelnewbies/1791

您无法在中断处理程序中睡眠，因为中断没有 支持流程上下文，因此无需重新安排时间 进入.换句话说，中断处理程序与任务无关， 所以没有什么可以睡觉"的，(更重要的是)没有什么可以 醒来."它们必须自动运行.

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.

这与其他操作系统没有什么不同.在大多数操作系统中， 中断没有线程化.但是，下半部分通常是这样.

This is not unlike other operating systems. In most operating systems, interrupts are not threaded. Bottom halves often are, however.

页面错误处理程序可以休眠的原因是仅调用它 通过在流程上下文中运行的代码.因为内核是自己的 内存不可分页，只有用户空间内存访问才能导致 页面错误.因此，只有几个特定的​​地方(例如 copy_ {to，from} _user())可能导致内核内出现页面错误.那些 所有地方都必须由可以休眠的代码(例如，流程上下文， 没有锁等).

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, et cetera).

这篇关于为什么在中断上下文中执行的内核代码/线程无法休眠?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！