最近在研究異步消息處理, 突然想起linux內核的中斷處理, 裡面由始至終都貫穿著"重要的事馬上做, 不重要的事推後做"的異步處理思想. 於是整理一下~
第一階段－－獲取中斷號
每個CPU都有響應中斷的能力, 每個CPU響應中斷時都走相同的流程. 這個流程就是內核提供的中斷服務程序.
在進入中斷服務程序時, CPU已經自動禁止了本CPU上的中斷響應, 因為CPU不能假定中斷服務程序是可重入的.
中斷處理程序的第一步要做兩件事情:
1. 將中斷號壓入棧中; (不同中斷號的中斷對應不同的中斷服務程序入口)
2. 將當前寄存器信息壓入棧中; (以便中斷退出時恢復)
顯然, 這兩步都是不可重入的(如果在保存寄存器值時被中斷了, 那麼另外的操作很可能就把寄存器給改寫了, 現場將無法恢復), 所以前面說到的CPU進入中斷服務程序時要自動禁止中斷.
棧上的信息被作為函數參數, 調用do_IRQ函數.
第二階段－－中斷串行化
進入do_IRQ函數, 第一步進行中斷的串行化處理, 將多個CPU同時產生的某一中斷進行串行化. 其方法是如果當前中斷處於"執行"狀態(表明另一個CPU正在處理相同的中斷), 則重新設置它的"觸發"標記, http://www.linuxidc.com然後立即返回. 正在處理同一中斷的那個CPU完成一次處理後, 會再次檢查"觸發"標記, 如果設置, 則再次觸發處理過程.
於是, 中斷的處理是一個循環過程, 每次循環調用handle_IRQ_event來處理中斷.
第三階段－－關中斷條件下的中斷處理
進入handle_IRQ_event函數, 調用對應的內核或內核模塊通過request_irq函數注冊的中斷處理函數.
注冊的中斷處理函數有個中斷開關屬性, 一般情況下, 中斷處理函數總是在關中斷的情況下進行的. 而調用request_irq注冊中斷處理函數時也可以設置該中斷處理函數在開中斷的情況下進行, 這種情況比較少見, 因為這要求中斷處理代碼必須是可重入的. (另外, 這裡如果開中斷, 正在處理的這個中斷一般也是會被阻塞的. 因為正在處理某個中斷的時候, 硬件中斷控制器上的這個中斷並未被ack, 硬件不會發起下一次相同的中斷.)
中斷處理函數的過程可能會很長, 如果整個過程都在關中斷的情況下進行, 那麼後續的中斷將被阻塞很長的時間.
於是, 有了soft_irq. 把不可重入的一部分在中斷處理程序中(關中斷)去完成, 然後調用raise_softirq設置一個軟中斷, 中斷處理程序結束. 後面的工作將放在soft_irq裡面去做.
