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

概述在早期版本的 Linux内核中,SMP系统中硬件IRQ的中断服务例程(ISR)在它们启动的CPU上执行,从开始到结束.如果被其他代码抢占,则ISR将在同一CPU上恢复. 但是在最近的内核中,大多数ISR默认情况下应该在特殊内核线程的上下文中执行(http://lwn.net/Articles/433854/). “普通”内核线程在被抢占时可以迁移到另一个CPU.所以问题是,无论出于何种原因,ISR 在早期版本的 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 voIDirq_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吗？全部内容，希望文章能够帮你解决linux-kernel – 抢占后,ISR可以迁移到其他CPU吗？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。