Linux 为什么中断不允许休眠?
所谓的睡眠,就是调用 schedule 让出 CPU,调度器选择另外个进程继续执行,这个过程涉及进程栈空间的切换。
1、假如中断上下文中调用 schedule ,此时获取的 struct thread info 数据结构是发生中断时该进程栈信息,而不是中断上下文调用 schedule 时任何信息。这就导致再也无法返回中断上下文中调用 schedule 的地方。
2、中断上下文处于关中断中,需要发送个 EOI 通知 GIC 中断处理结束,GIC 和CPUinterface 才会进入下一次中断处理。如果中途 schedule,那么整个系统的中断都会被屏蔽掉。
一般进入中断后,需要关中断,也会关抢占,同时注意不可以调用schedule。
unhandled interrupt 和 spurious interrupt
未处理中断和虚假中断
在中断处理的最后,总会有一段代码如下:
irqreturn_t
handle_irq_event_percpu(structirq_desc*desc,structirqaction*action)
{
……
if(!noirqdebug)
note_interrupt(irq,desc,retval);
returnretval;
}
note_interrupt就是进行unhandled interrupt和spurious interrupt处理的。对于这类中断,linux kernel有一套复杂的机制来处理,你可以通过command line参数(noirqdebug)来控制开关该功能。
当发生了一个中断,但是没有被处理(有两种可能,一种是根本没有注册的 specific handler,第二种是有 handler,但是 handler 否认是自己对应的设备触发的中断),怎么办?毫无疑问这是一个异常状况,那么 kernel 是否要立刻采取措施将该 IRQ disable 呢?也不太合适,毕竟 interrupt request 信号线是允许共享的,直接 disable 该 IRQ 有可能会下手太狠,kernel 采取了这样的策略:如果该 IRQ 触发了 100,000 次,但是 99,900 次没有处理,在这种条件下,我们就是 disable 这个 interrupt request line。
中断线和中断号是一个意思。
相关的控制数据在中断描述符中,如下:
structirq_desc{
……
unsignedintirq_count;--------记录发生的中断的次数,每100,000则回滚
unsignedlonglast_unhandled;-----上一次没有处理的IRQ的时间点
unsignedintirqs_unhandled;------没有处理的次数
……
}
-
cpu
+关注
关注
68文章
10856浏览量
211626 -
Linux
+关注
关注
87文章
11297浏览量
209369 -
中断
+关注
关注
5文章
898浏览量
41476
发布评论请先 登录
相关推荐
评论