ULK第3版第4.6章中关于IRQ_REPLAY的问题

dengcainiao

spin_lock_irqrestore(&(irq_desc.lock), flags)过程中未必就一定开中断了，是否开中断还要看加锁前的中断状态，如果加锁前中断状态是打开的执行到这里当然就是打开的，否则执行完这个以后也有可能是关中断的。

zx_wing

原帖由 OstrichFly 于 2008-6-11 10:09 发表

谢谢！
我理解了你说的“IPI在开中断以后才会被提交，即在spin_lock_irqrestore(&(irq_desc.lock), flags);之后”。
但严格来说，提交IPI应该是在spin_lock_irqrestore(&(irq_desc.lock), flags)内部，中断 ...

呵呵，看LZ用了好多“飞快的”这样的形容词，以前我也会对有些看似不大可能的问题用这种词假设。
其实不一定要“飞快的”，很多情况都可以使处理IPI的CPU“慢下来”，例如在关中断这个期间，一个比IPI优先级更高的中断发生了（当然，比IPI优先级更高的中断都是关不掉的），就会先去处理这个中断。实际上这个比IPI优先级更高的，又可以被屏蔽的中断也只有IPI本身了。linux一共使用了三种IPI：RESCHEDULE IPI、INVALIDATE_TLB_VECTOR IPI、CALL_FUNCTION IPI。其中CALL_FUNCTION IPI是种通用IPI，也就是一个CPU通知另一个CPU干个啥事儿（本版另一个帖子问CPU的通讯方式，这就是一种），resend_irq用的就是这种。例如在中断关闭期间，其它CPU发送了一个INVALIDATE_TLB_VECTOR IPI给该CPU，则开中断后会先执行它，resend_irq就被推后了，这时其它CPU有大把的时间来做disable/enable的工作。其次，即使执行resend_irq的IPI时，其它CPU也有机会做disable/enable的，处理并发情况不能假设谁执行的快或慢。
此外，目前的kernel已经倾向于使用过tasklet来做resend_irq了，那其它CPU就更有机会在该CPU执行resend_irq前做disable/enable的工作。
UP当然没有这个考虑，大部分复杂性都是SMP引入的

OstrichFly

>> 此外，目前的kernel已经倾向于使用过tasklet来做resend_irq了，那其它CPU就更有机会在该CPU执行resend_irq前做disable/enable的工作。
是的，我看到最新内核中用的已经是tasklet了，也就根本不存在这个帖子中的提问了。

原以为linux中所有中断的优先级相同，但没考虑到IPI。明白了，谢谢！

zx_wing

原帖由 OstrichFly 于 2008-6-11 13:30 发表
>> 此外，目前的kernel已经倾向于使用过tasklet来做resend_irq了，那其它CPU就更有机会在该CPU执行resend_irq前做disable/enable的工作。
是的，我看到最新内核中用的已经是tasklet了，也就根本不存在这个帖子 ...

tasklet为啥没这个问题？
咦，又想起一个问题，是哪个方式可以跨CPU执行，是work queue吗？不记得了，手边又没书。

[ 本帖最后由 zx_wing 于 2008-6-11 22:31 编辑 ]

dengcainiao

软中断就可以同时在多个CPU上并发执行啊

zx_wing

原帖由 dengcainiao 于 2008-6-11 22:50 发表
软中断就可以同时在多个CPU上并发执行啊

软中断是per cpu的嘛，不是那种global的，也就是说想进程这样从一个CPU跑到另一个CPU去执行的

OstrichFly

原帖由 zx_wing 于 2008-6-11 22:27 发表

tasklet为啥没这个问题？
咦，又想起一个问题，是哪个方式可以跨CPU执行，是work queue吗？不记得了，手边又没书。

我的意思是：
不用软中断的话，原先认为IRQ_REPLAY不存在也不会出现多个中断发生，因此在1楼我问了“为什么IRQ_REPLAY必须存在”这个问题。
如果用了软中断，处理会被推后，很明显有可能再次发生renable事件，也就需要IRQ_REPLAY来避免中断重复。因此就不用问1楼的问题了。