ULK第3版第4.6章中關(guān)于IRQ_REPLAY的問題

dengcainiao

spin_lock_irqrestore(&(irq_desc.lock), flags)過程中未必就一定開中斷了，是否開中斷還要看加鎖前的中斷狀態(tài)，如果加鎖前中斷狀態(tài)是打開的執(zhí)行到這里當(dāng)然就是打開的，否則執(zhí)行完這個以后也有可能是關(guān)中斷的。

zx_wing

原帖由 OstrichFly 于 2008-6-11 10:09 發(fā)表

謝謝！
我理解了你說的“IPI在開中斷以后才會被提交，即在spin_lock_irqrestore(&(irq_desc.lock), flags);之后”。
但嚴(yán)格來說，提交IPI應(yīng)該是在spin_lock_irqrestore(&(irq_desc.lock), flags)內(nèi)部，中斷 ...

呵呵，看LZ用了好多“飛快的”這樣的形容詞，以前我也會對有些看似不大可能的問題用這種詞假設(shè)。
其實不一定要“飛快的”，很多情況都可以使處理IPI的CPU“慢下來”，例如在關(guān)中斷這個期間，一個比IPI優(yōu)先級更高的中斷發(fā)生了（當(dāng)然，比IPI優(yōu)先級更高的中斷都是關(guān)不掉的），就會先去處理這個中斷。實際上這個比IPI優(yōu)先級更高的，又可以被屏蔽的中斷也只有IPI本身了。linux一共使用了三種IPI：RESCHEDULE IPI、INVALIDATE_TLB_VECTOR IPI、CALL_FUNCTION IPI。其中CALL_FUNCTION IPI是種通用IPI，也就是一個CPU通知另一個CPU干個啥事兒（本版另一個帖子問CPU的通訊方式，這就是一種），resend_irq用的就是這種。例如在中斷關(guān)閉期間，其它CPU發(fā)送了一個INVALIDATE_TLB_VECTOR IPI給該CPU，則開中斷后會先執(zhí)行它，resend_irq就被推后了，這時其它CPU有大把的時間來做disable/enable的工作。其次，即使執(zhí)行resend_irq的IPI時，其它CPU也有機會做disable/enable的，處理并發(fā)情況不能假設(shè)誰執(zhí)行的快或慢。
此外，目前的kernel已經(jīng)傾向于使用過tasklet來做resend_irq了，那其它CPU就更有機會在該CPU執(zhí)行resend_irq前做disable/enable的工作。
UP當(dāng)然沒有這個考慮，大部分復(fù)雜性都是SMP引入的

OstrichFly

>> 此外，目前的kernel已經(jīng)傾向于使用過tasklet來做resend_irq了，那其它CPU就更有機會在該CPU執(zhí)行resend_irq前做disable/enable的工作。
是的，我看到最新內(nèi)核中用的已經(jīng)是tasklet了，也就根本不存在這個帖子中的提問了。

原以為linux中所有中斷的優(yōu)先級相同，但沒考慮到IPI。明白了，謝謝！

zx_wing

原帖由 OstrichFly 于 2008-6-11 13:30 發(fā)表
>> 此外，目前的kernel已經(jīng)傾向于使用過tasklet來做resend_irq了，那其它CPU就更有機會在該CPU執(zhí)行resend_irq前做disable/enable的工作。
是的，我看到最新內(nèi)核中用的已經(jīng)是tasklet了，也就根本不存在這個帖子 ...

tasklet為啥沒這個問題？
咦，又想起一個問題，是哪個方式可以跨CPU執(zhí)行，是work queue嗎？不記得了，手邊又沒書。

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

dengcainiao

軟中斷就可以同時在多個CPU上并發(fā)執(zhí)行啊

zx_wing

原帖由 dengcainiao 于 2008-6-11 22:50 發(fā)表
軟中斷就可以同時在多個CPU上并發(fā)執(zhí)行啊

軟中斷是per cpu的嘛，不是那種global的，也就是說想進程這樣從一個CPU跑到另一個CPU去執(zhí)行的

OstrichFly

原帖由 zx_wing 于 2008-6-11 22:27 發(fā)表

tasklet為啥沒這個問題？
咦，又想起一個問題，是哪個方式可以跨CPU執(zhí)行，是work queue嗎？不記得了，手邊又沒書。

我的意思是：
不用軟中斷的話，原先認為IRQ_REPLAY不存在也不會出現(xiàn)多個中斷發(fā)生，因此在1樓我問了“為什么IRQ_REPLAY必須存在”這個問題。
如果用了軟中斷，處理會被推后，很明顯有可能再次發(fā)生renable事件，也就需要IRQ_REPLAY來避免中斷重復(fù)。因此就不用問1樓的問題了。