Linux kernel ISR在被抢占时能否迁移到其他CPU?

Linux kernel ISR在被抢占时能否迁移到其他CPU?,linux-kernel,linux-device-driver,Linux Kernel,Linux Device Driver,在旧版本的Linux内核中,SMP系统中硬件IRQ的中断服务例程(ISR)自始至终都在CPU上执行。如果被其他代码抢占,ISR将在同一CPU上恢复 但是在最近的内核中,默认情况下,大多数ISR都应该在特殊内核线程的上下文中执行()。当被抢占时,“普通”内核线程可以迁移到另一个CPU。所以问题是,无论出于何种原因,ISR现在是否也能做这样的事情 注意,我不是在谈论IRQ的CPU亲和力和处理器之间的IRQ平衡。我对中断处理程序已经在运行但被抢占的情况感到好奇 也就是说,假设ISR已经开始在CPU#1

在旧版本的Linux内核中,SMP系统中硬件IRQ的中断服务例程(ISR)自始至终都在CPU上执行。如果被其他代码抢占,ISR将在同一CPU上恢复

但是在最近的内核中,默认情况下,大多数ISR都应该在特殊内核线程的上下文中执行()。当被抢占时,“普通”内核线程可以迁移到另一个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();
}

这是有道理的。谢谢你的解释!