所谓的睡眠,就是调用 schedule 让出 CPU,调度器选择另外个进程继续执行,这个过程涉及进程栈空间的切换。
1、假如中断上下文中调用 schedule ,此时获取的 struct thread info 数据结构是发生中断时该进程栈信息,而不是中断上下文调用 schedule 时任何信息。这就导致再也无法返回中断上下文中调用 schedule 的地方。
2、中断上下文处于关中断中,需要发送个 EOI 通知 GIC 中断处理结束,GIC 和CPUinterface 才会进入下一次中断处理。如果中途 schedule,那么整个系统的中断都会被屏蔽掉。
一般进入中断后,需要关中断,也会关抢占,同时注意不可以调用schedule。
未处理中断和虚假中断
在中断处理的最后,总会有一段代码如下:
irqreturn_t
handle_irq_event_percpu(struct irq_desc *desc, struct irqaction *action)
{
……
if (!noirqdebug)
note_interrupt(irq, desc, retval);
return retval;
}
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。
中断线和中断号是一个意思。
相关的控制数据在中断描述符中,如下:
struct irq_desc {
……
unsigned int irq_count;--------记录发生的中断的次数,每100,000则回滚
unsigned long last_unhandled;-----上一次没有处理的IRQ的时间点
unsigned int irqs_unhandled;------没有处理的次数
……
}
全部0条评论
快来发表一下你的评论吧 !