假设我们收到来自 Net 设备的 100 个中断，来自 USB 的 50 个中断，来自 SPI 设备的 25 个中断，来自 I2c 的 25 个中断。
按如下顺序来 5Net - 4USB - 2SPI -2I2C 和相同的序列如下。
顶级处理程序可以调度特定于设备的处理程序来服务中断
现在处理器一旦得到网络设备的中断就会中断正在运行的任务。在完成 Net 设备的中断处理程序的上半部分后，它必须执行 USB 和 SPI 和 I2C 的上半部分。
完成第一组序列后将遵循相同的序列。被打断的任务什么时候会再次唤醒？被中断的任务是否等到所有 100 个中断都由它们各自的设备特定处理程序提供服务？如果多核系统需要服务数十万个中断，如何将中断共享给不同的内核？
据我所知，在执行中断处理程序时，处理器将处于中断上下文中，因此不会有任何上下文切换。由于不同的 ISR 必须服务数十万个中断，处理器是否总是处于中断上下文中？
【问题讨论】：
标签： linux-kernel interrupt-handling
被打断的任务什么时候会再次唤醒？
当中断被清除并且调度器决定给这个任务处理器时间。
被中断的任务是否要等到所有 100 个中断都由它们各自的设备特定处理程序提供服务？
您只描述了 4 个 IRQ 源（一些网络设备、usb、spi、i2c）。因此，如果所有 IRQ 线路都为高电平并启用，则处理这些 irq 的 CPU 将切换到特定的中断处理程序。如果在处理程序之后仍然触发中断，则为其提供服务的 cpu 将一次又一次地分支到中断处理程序，直到中断被清除。在具有 5 个 cpu 的多 cpu 系统上，4 个可能同时为您的设备执行中断处理程序，而另一个将执行您的任务。所以你的任务可能根本不会被打断。或者，当中断处理程序编写错误并且永远不会清除 IRQ 行时，它可能会在单个 cpu 系统上永远等待 cpu。
如果多核系统需要处理数十万个中断，如何将中断共享给不同的内核？
我认为最好在这里解释：multi-core CPU interrupts。
由于不同的 ISR 将不得不服务数十万个中断，处理器是否总是处于中断上下文中？
它将保持在中断上下文中，直到启用 IRQ 并触发 IRQ。如果需要，您可以禁用 IRQ 线路并将 cpu 返回给调度程序。
【讨论】：