在x86上，当OS禁用中断时，它们消失了，还是排队并“等待"中断再次出现? [英] On x86, when the OS disables interrupts, do they vanish, or do they queue and 'wait' for interrupts to come back on?
问题描述
在Windows上，我的平台是x86和x86-64.
My platform is x86 and x86-64, on Windows.
中断优先级系统的重点是使优先级最高的中断击败其他中断.为此，我猜测Windows将完全禁用所有较低级别的中断，直到完成较高级别中断的ISR.
The point of the interrupt priority system is to have the highest priority interrupt beat out the others. To enforce this, I'm guessing that Windows will disable all interrupts of lower level completely, until the ISR for the higher-level interrupt is complete.
但是，如果CPU不监听中断，会发生什么?他们只是默默消失了吗?还是他们在硬件中排队，等待中断再次启用?如果将它们存储在哪里?排队人数有限制吗?如果有太多中断未处理，会发生什么?如果在极少数情况下积压了中断处理，可以使用什么工具来检测问题?
But if the CPU isn't listening to interrupts, what happens? Do they just silently disappear? Or are they queued in hardware, waiting for interrupts to become enabled again? If they are stored, where? Are there limitations to how many can queue up? What happens if too many interrupts go unprocessed? What instrumentation exists to detect issues, in case there are rare conditions where interrupt handling gets backlogged?
推荐答案
某些背景
外围设备的中断不是直接由CPU处理，而是由称为可编程中断控制器"的硬件直接处理.较早的系统使用PIC-(Intel 8259 )，但是由于缺乏对SMP系统的支持，如今Adavnced PIC-APIC(英特尔 82093 ). APIC有两个组件，IO APIC(主板的一部分)将这些中断请求转发到本地APIC(CPU的一部分).
但是这些硬件只是将消息传递给CPU，实际的处理是由特定设备的设备驱动程序完成的.
Interrupts from the peripherals are not directly handled by the CPU, instead by a hardware called "Programmable Interrupt Controller". Earlier systems used a PIC - (Intel 8259) but due to its lack of support for SMP systems, nowadays Adavnced PIC - APIC (Intel 82093) is used. APIC has two components, IO APIC (part of motherboard) forwards these interrupt requests to the local APIC (part of the CPU).
But these hardwares just pass the messages to the CPU, the actual handling is done by the device driver of the particular device.
正在回答您的问题
但是，如果CPU不监听中断，会发生什么?他们只是默默消失了吗?还是他们在硬件中排队，等待中断再次启用?
But if the CPU isn't listening to interrupts, what happens? Do they just silently disappear? Or are they queued in hardware, waiting for interrupts to become enabled again?
这篇文章讨论了两类中断处理程序，具体取决于它们执行的速度:
1.快速:在禁用其他中断的情况下运行，
2.慢:在启用中断的情况下运行.
但是现在由于任务集/工作队列(上半部分和下半部分-敲钟了吗?)使处理程序的执行时间变得非常短，因此两者之间的区别已经过时了，因此如今的中断处理程序在启用了中断的情况下运行.对于I2C等较慢的设备，我们已经采用了称为线程化中断处理程序的新技术，它甚至更好.而不是上/下半部方法.如果对于某些设备而言，如果上述技术不起作用，则处理程序将在禁用中断的情况下执行，是的，在这种情况下，您会不断丢失中断，但我找不到发生这种情况的任何实例.
This article talks about two classes of interrupts handlers depending upon how fast they are executed:
1. Fast: Run with further interrupts disabled,
2. Slow: Run with interrupts enabled.
But now the distinction between the two has become obsolete since tasklets/work queues (top & bottom halfs - rings a bell?) have made the execution time of the handlers very less, hence nowadays interrupts handlers are run with interrupts enabled. For slower devices like I2C, we have moved to a new technique called Threaded Interrupt Handler, which is even better than the top/bottom half approach. In case for some device if the above techniques don't work, than the handler is executed with interrupts disabled and yes in that case, you keep losing the interrupts, but I can't find any instance where such a thing happens.
如果将它们存储在哪里?排队人数有限制吗?如果有太多中断未处理，会发生什么?
If they are stored, where? Are there limitations to how many can queue up? What happens if too many interrupts go unprocessed?
不，它们没有排队，如果需要禁用中断，并且中断时间较长，那么这是一个糟糕的中断处理程序设计.
No, they are not queued up, it is a bad interrupt handler design if the interrupts need to be disabled and that too for a longer time.
在极少数情况下积压了中断处理的情况下，存在哪些检测问题的工具?
What instrumentation exists to detect issues, in case there are rare conditions where interrupt handling gets backlogged?
如果禁用了中断，那么您将无能为力，但是如果启用了中断，并且您不断收到更多的中断，则可能导致中断的嵌套，以至于系统可能崩溃.然后可以使用核心转储来检测原因.
If the interrupts are disabled then there nothing that you can do, but if they are enabled and you keep getting more interrupts then it leads to nesting of interrupts, to the extent that the system might crash. A core dump then can be used to detect the cause.
这篇关于在x86上，当OS禁用中断时，它们消失了，还是排队并“等待"中断再次出现?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
