抢占时,ISR是否可以迁移到其他CPU?

问题描述:

在早期版本的Linux内核中,SMP系统中硬件IRQ的中断服务例程(ISR)在其开始的CPU上执行,从头到尾。如果被其他代码抢占,则ISR会在同一CPU上恢复。抢占时,ISR是否可以迁移到其他CPU?

但在最近的内核,大多数的ISR应该在特殊的内核线程的默认(http://lwn.net/Articles/433854/)上下文中执行。抢占时,“普通”内核线程可以迁移到另一个CPU。所以问题是,无论出于何种原因,ISR现在是否也可以这样做?

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

也就是说,假设一个ISR已经开始对CPU 1#执行。现在它被一些更高优先级的代码占先。当后者完成其工作时,ISR恢复执行 - 但在CPU#2上。这种情况可能吗?

到相关的文档,讨论等指针,随时欢迎。

的ISR线程都作为ISR例程相同的亲和力,所以在抢占的情况下,ISR线程不会重新安排到任意的CPU。

此外,强迫中断服务程序成为线程的行为默认情况下不会根据你提供的链接信息启用。它受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(); 
} 
+0

这是有道理的。谢谢你的解释! – Eugene 2011-11-06 14:22:54