为什么需要中断上下文? [英] Why do we need Interrupt context?
问题描述
我有疑问，为什么我们到底需要中断上下文?一切都说明了这些属性是什么，但没有人解释为什么我们要提出这个概念?
I am having doubts, why exactly we need interrupt context? Everything tells what are the properties but no one explains why we come up with this concept?
与同一概念有关的另一个疑问是，如果我们不禁用中断处理程序中的中断，那么在中断上下文中运行此中断处理程序代码有什么用?
Another doubt related to same concept is, If we are not disabling the interrupt in interrupt handler, then what is the use of running this interrupt handler code in interrupt context ?
推荐答案
我们为什么需要中断上下文?
Why do we need Interrupt context?
首先，中断上下文是什么意思?上下文通常是一种状态.有两个独立的状态概念.
First, what do we mean by interrupt context? A context is usually a state. There are two separate concepts of state.
每个CPU体系结构都有处理中断的机制.可能有一个单个中断向量被称为每个系统中断，或者CPU/硬件可能能够根据中断源将CPU分配到特定的地址.也有用于屏蔽/取消屏蔽中断的机制.每个中断都可能被单独屏蔽，或者可能对整个CPU都具有全局屏蔽.最后，有一个实际的CPU状态.有些可能具有单独的堆栈，寄存器集和CPU模式，这暗示着一些内存和其他特权.您的问题是关于Linux的，它必须处理所有情况.
Every CPU architecture has a mechanism for handling interrupts. There maybe a single interrupt vector called for every system interrupt, or the CPU/hardware may be capable of dispatching the CPU to a particular address based on the interrupt source. There are also mechanisms for masking/unmasking interrupts. Each interrupt maybe masked individually, or there maybe a global mask for the entire CPU(s). Finally, there is an actual CPU state. Some may have separate stacks, register sets, and CPU modes implying some memory and other privileges. Your question is about Linux in general and it must handle all cases.
通常，所有体系结构都有单独的内核堆栈，每个进程的进程上下文(ala ps)和 VM (虚拟内存)上下文. VM 对 user 和 kernel 模式具有不同的特权.为了使内核始终运行，必须为设备上的所有进程保持映射状态. 内核线程是一种特殊情况，它不太关心 VM ，因为它具有特权并可以访问所有内核内存.但是，它确实具有单独的堆栈和进程上下文.用户寄存器通常在 exceptions 发生时存储在内核堆栈上.异常至少是页面错误，系统调用和中断.这些物品可能会嵌套.即，您可以从用户空间调用write()，而当内核正在传输用户缓冲区时，它可能会出现页面错误以读取一些换出的用户空间数据. 页面错误可能再次需要服务中断.
Generally all of the architectures have a separate kernel stack, process context (ala ps) and VM (virtual memory) context for each process. The VM has different privileges for user and kernel modes. In order for the kernel to run all the time, it must remain mapped for all processes on a device. A kernel thread is a special case that doesn't care so much about the VM, because it is privileged and can access all kernel memory. However, it does have a separate stack and process context. User registers are typically stored upon the kernel stack when exceptions happen. Exceptions are at least page faults, system calls and interrupts. These items may nest. Ie, you may call write() from user space and while the kernel is transferring a user buffer, it may page fault to read some swapped out user space data. The page fault may again have to service an interrupt.
Linux一般要让您屏蔽中断，因为 VM ，执行和进程管理(上下文和上下文切换)必须协同工作.为了使 VM 变得简单，内核堆栈和进程上下文通常植根于单个 VM 页面的单个4k(或8k)区域中.此页面始终是映射的.通常，在为中断提供服务时，所有CPU将从中断模式切换为系统模式，并使用与所有其他异常相同的内核堆栈.堆栈很小，因此允许递归(以及较大的堆栈分配)会炸毁堆栈，从而导致内核级别的堆栈溢出.不好.
Linux general wants you to leave interrupts masked as the VM, the execptions, and process management (context and context switching) have to work together. In order to keep things simple for the VM, the kernel stack and process context are generally rooted in either a single 4k (or 8k) area which is a single VM page. This page is always mapped. Typically, all CPUs will switch from interrupt mode to system mode when servicing an interrupt and use the same kernel stack as all other exceptions. The stack is small so to allow recursion (and large stack allocation) can blow up the stack resulting in stack overflows at the kernel level. This is bad.
许多内核结构需要在多个总线周期内保持一致；即，添加元素时，链表必须同时更新prev和next节点链接.执行此操作的典型机制可能是屏蔽中断，以确保代码是原子的.某些CPU可能允许总线锁定，但这不是通用的.上下文切换代码也必须是原子的.中断的结果通常是重新计划.也就是说，内核中断处理程序可能已经write()中写入更多缓冲的数据.
Many kernel structures need to stay consistent over multiple bus cycles; Ie, a linked list must update both prev and next node links when adding an element. A typical mechanism to do this maybe to mask interrupts, to ensure the code is atomic. Some CPUs may allow bus locking, but this is not universal. The context switching code must also be atomic. A consequence of an interrupt is typically rescheduling. Ie, a kernel interrupt handler may have acked a disk controller and started a write operation. Then a kernel thread may schedule to write more buffered data from the original user space write().
随时发生的中断可能会破坏某些子系统对原子行为的假设.不允许中断使用子系统，禁止他们使用子系统.
Interrupts occurring at any time can break some sub-sytem's assumptions of atomic behavior. Instead of allowing interrupt to use the sub-system, they are prohibited from using it.
Linux必须处理三件事.当前进程执行上下文，当前虚拟内存布局和硬件请求.他们都需要共同努力.由于中断可能随时发生，因此它们发生在任何流程上下文中.在中断中使用sleep()等将使随机进程进入睡眠状态.允许在中断中分配大量堆栈可能会炸毁有限的堆栈.这些设计选择限制了Linux中断处理程序中可能发生的情况.各种配置选项都可以允许重入中断，但这通常是特定于CPU的.
Linux must handle three thing. The current process execution context, the current virtual memory layout and hardware requests. They all need to work together. As the interrupts may happen at any time, they occur in any process context. Using sleep(), etc in an interrupt would put random processes to sleep. Allowing large stack allocation in an interrupt could blow up the limited stack. These design choices limit what can happen in a Linux interrupt handler. Various configuration options can allow re-entrant interrupts, but this is often CPU specific.
保持上半部的优势，现在主要的中断处理程序较小，这是减少了中断等待时间.繁忙的工作应该在内核线程中完成.需要 un-mask 中断的中断服务例程已经对Linux生态系统有些反社会了.该工作应放在内核线程中.
A benefit of keeping the top half, now the main interrupt handler small is that interrupt latency is reduced. Busy work should be done in a kernel thread. An interrupt service routine that would need to un-mask interrupts is already somewhat anti-social to the Linux eco-system. That work should be put in a kernel thread.
从某种意义上说， Linux中断上下文确实不存在.这只是在任何进程上下文中都可能发生的CPU中断.实际上， Linux中断上下文是一组编码限制.
The Linux interrupt context really doesn't exist in some sense. It is only a CPU interrupt which may happen in any process context. The Linux interrupt context is actually a set of coding limitations that happen as a consequence of this.
这篇关于为什么需要中断上下文?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
