linux-kernel - 抢占后，ISR可以迁移到其他CPU吗？

在较早版本的Linux内核中，SMP系统中硬件IRQ的中断服务例程(ISR)从头到尾都在它们开始的CPU上执行。如果被其他代码取代，则ISR随后将在同一CPU上恢复。

但是在最新的内核中，默认情况下，大多数ISR应该在特殊内核线程(http://lwn.net/Articles/433854/)的上下文中执行。被抢占的“普通”内核线程可以迁移到另一个CPU。因此，问题是，ISR是否可以出于某种原因现在也做此类事情？

请注意，我不是在谈论IRQ的CPU亲和力和处理器之间的IRQ平衡。我对中断处理程序已经在运行但被抢占的情况感到好奇。

也就是说，假设一个ISR已经开始在CPU＃1上执行。现在，它被一些更高优先级的代码抢占了。后者完成工作后，ISR恢复执行-但在CPU＃2上。这样的情况可能吗？

始终欢迎提供指向相关文档，讨论等的指针。

最佳答案

ISR线程与ISR例程具有相同的相似性，因此在抢占的情况下，ISR线程将不会重新调度到任意CPU。

另外，根据您提供的链接中的信息，默认情况下不启用强制ISR成为线程的行为。它由threadirqs命令行选项限制。命令行选项的处理以传统ISR无需关心重新计划的方式来处理ISR线程。根据kernel/irq/manage.c中的以下代码，这些线程禁用了抢占:

/*
 * Interrupts which are not explicitely requested as threaded
 * interrupts rely on the implicit bh/preempt disable of the hard irq
 * context. So we need to disable bh here to avoid deadlocks and other
 * side effects.
 */
static void
irq_forced_thread_fn(struct irq_desc *desc, struct irqaction *action)
{
        local_bh_disable();
        action->thread_fn(action->irq, action->dev_id);
        irq_finalize_oneshot(desc, action, false);
        local_bh_enable();
}

关于linux-kernel - 抢占后，ISR可以迁移到其他CPU吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/6058804/