linux中斷處理淺析

最近在研究非同步訊息處理, 突然想起linux核心的中斷處理, 裡面由始至終都貫穿著"重要的事馬上做, 不重要的事推後做"的非同步處理思想. 於是整理一下~

第一階段－－擷取中斷號
每個CPU都有響應中斷的能力, 每個CPU響應中斷時都走相同的流程. 這個流程就是核心提供的中斷服務程式.
在進入中斷服務程式時, CPU已經自動禁止了本CPU上的中斷響應, 因為CPU不能假定中斷服務程式是可重新進入的.
中斷處理常式的第一步要做兩件事情:
1. 將中斷號壓入棧中; (不同中斷號的中斷對應不同的中斷服務程式入口)
2. 將當前寄存器資訊壓入棧中; (以便中斷退出時恢複)
顯然, 這兩步都是不可重新進入的(如果在儲存寄存器值時被中斷了, 那麼另外的操作很可能就把寄存器給改寫了, 現場將無法恢複), 所以前面說到的CPU進入中斷服務程式時要自動禁止中斷.
棧上的資訊被作為函數參數, 調用do_IRQ函數.

第二階段－－中斷序列化
進入do_IRQ函數, 第一步進行中斷的序列化處理, 將多個CPU同時產生的某一中斷進行序列化. 其方法是如果當前中斷處於"執行"狀態(表明另一個CPU正在處理相同的中斷), 則重新設定它的"觸發"標記, 然後立即返回. 正在處理同一中斷的那個CPU完成一次處理後, 會再次檢查"觸發"標記, 如果設定, 則再次觸發處理過程.
於是, 中斷的處理是一個迴圈過程, 每次迴圈調用handle_IRQ_event來處理中斷.

第三階段－－關中斷條件下的中斷處理
進入handle_IRQ_event函數, 調用對應的核心或核心模組通過request_irq函數註冊的中斷處理函數.
註冊的中斷處理函數有個中斷開關屬性, 一般情況下, 中斷處理函數總是在關中斷的情況下進行的. 而調用request_irq註冊中斷處理函數時也可以設定該中斷處理函數在開中斷的情況下進行, 這種情況比較少見, 因為這要求中斷處理代碼必須是可重新進入的. (另外, 這裡如果開中斷, 正在處理的這個中斷一般也是會被阻塞的. 因為正在處理某個中斷的時候, 硬體中斷控制器上的這個中斷並未被ack, 硬體不會發起下一次相同的中斷.)
中斷處理函數的過程可能會很長, 如果整個過程都在關中斷的情況下進行, 那麼後續的中斷將被阻塞很長的時間. 
於是, 有了soft_irq. 把不可重新進入的一部分在中斷處理常式中(關中斷)去完成, 然後調用raise_softirq設定一個非強制中斷, 中斷處理常式結束. 後面的工作將放在soft_irq裡面去做.

第四階段－－開中斷條件下的非強制中斷
上一階段迴圈調用完當前所有被觸發的中斷處理函數後, do_softirq函數被調用, 開始處理軟體中斷. 
在非強制中斷機制中, 為每個CPU維護了一個若干位的掩碼集, 每位元遮罩代表一個中斷號. 在上一階段的中斷處理函數中, 調用raise_softirq設定了對應的非強制中斷, 到了這裡, 非強制中斷對應的處理函數就會被調用(處理函數由open_softirq函數來註冊). 
可以看出, 非強制中斷與中斷的模型很類似, 每個CPU有一組中斷號, 中斷有其對應的優先順序, 每個CPU處理屬於自己的中斷. 最大的不同是開中斷與關中斷. 
於是, 一個中斷處理過程被分成了兩部分, 第一部分在中斷處理函數裡面關中斷的進行, 第二部分在非強制中斷處理函數裡面開中斷的進行.

由於這一步是在開中斷條件下進行的，這裡還可能發生新的中斷（中斷嵌套），然後新中斷對應的中斷處理又將開始一個新的第一階段~第三階段。在新的這個第三階段中，可能又會觸發新的非強制中斷。但是這個新的中斷處理過程並不會進入第四階段，而是當它發現自己是嵌套的中斷時，完成第三階段之後就會退出了。也就是說，只有第一層中斷處理過程會進入第四階段，嵌套發生的中斷處理過程只執行到第三階段。

然而嵌套發生的中斷處理過程也可能會觸發非強制中斷，所以第一層中斷處理過程在第四階段需要是一個迴圈的過程，需要迴圈處理嵌套發生的所有非強制中斷。為什麼要這樣做呢？因為這樣可以按非強制中斷觸發的順序來執行這些非強制中斷，否則後來的非強制中斷可能就會先執行完成了。

極端情況下，嵌套發生的非強制中斷可能非常多，全部處理完可能需要很長的時間，於是核心會在處理完一定數量的非強制中斷後，將剩下未處理的非強制中斷推給一個叫ksoftirqd的核心線程來處理，然後結束本次中斷處理過程。

第五階段－－開中斷條件下的tasklet
實際上, 非強制中斷很少直接被使用. 而第二部分開中斷情況下的進行的處理過程一般是由tasklet機制來完成的.
tasklet是由非強制中斷引出的, 核心定義了兩個非強制中斷掩碼HI_SOFTIRQ和TASKLET_SOFTIRQ(兩者優先順序不同), 這兩個掩碼對應的非強制中斷處理函數作為入口, 進入tasklet處理過程.
於是, 在第三階段的中斷處理函數中, 完成關中斷的部分後, 然後調用tasklet_schedule/tasklet_hi_schedule標記一個tasklet, 然後中斷處理常式結束. 後面的工作由HI_SOFTIRQ/TASKLET_SOFTIRQ對應的非強制中斷處理常式去處理被標記的tasklet(每個tasklet在其初始化時都設定了處理函數). 
看上去, tasklet只不過是在softirq的基礎上多了一層調用, 其作用是什麼呢? 前面說過, softirq是與CPU相對應的, 每個CPU處理自己的softirq.
這些softirq的處理函數需要設計為可重新進入的, 因為它們可能在多個CPU上同時運行. 而tasklet則是在多個CPU間被序列化執行的, 其處理函數不必考慮可重新進入的事情. 
然而, softirq畢竟還是要比tasklet少繞點彎路, 所以少數即時性要求相對較高的處理過程還是在精心設計之後, 直接使用softirq了. 比如: 時鐘中斷處理過程, 網路發送/接收處理過程.

結尾階段
CPU接收到中斷以後, 以曆以上五個階段, 中斷處理完成. 最後需要恢複第一階段中被儲存在棧上的寄存器資訊. 中斷處理結束.

關於調度
上面的流程中, 還隱含了一個問題, 整個處理過程是持續佔有CPU的(除了開中斷情況下可能被新的中斷打斷以外). 並且,
中斷處理的這幾個階段中, 程式不能夠讓出CPU!
這是由核心的設計決定的, 中斷服務程式沒有自己的task結構(即作業系統教科書上說的進程式控制制塊), 所以它不能被核心調度. 通常說一個進程讓出CPU, 在之後如果滿足某種條件, 核心會通過它的task結構找到它, 並調度其運行.
這裡可能存在兩方面的問題:
1. 連續的低優先的中斷可能持續佔有CPU, 而高優先的某些進程則無法獲得CPU;
2. 中斷處理的這幾個階段中不能調用可能導致睡眠的函數(包括分配記憶體);
對於第一個問題, 較新的linux核心增加了ksoftirqd核心線程, 如果持續處理的softirq超過一定數量, 則結束中斷處理過程, 然後喚醒ksoftirqd, 讓它來繼續處理. 雖然softirq可能被推後到ksoftirqd核心線程去處理, 但是還是不能在softirq處理過程中睡眠, 因為不能保證softirq一定在ksoftirqd核心線程中被處理.
據說在montavista(一種嵌入式即時linux)中, 將核心的中斷機製做了修改. (某些中斷的)中斷處理過程被賦予了task結構, 能夠被核心調度. 解決了上述兩個問題. (montavista的目標是即時性, 這樣的做法犧牲了一定的整體效能.)

工作隊列
linux基準版本的核心在解決上述問題上, 提供了workqueue機制. 
定義一個work結構(包含了處理函數), 然後在上述的中斷處理的幾個階段的某一步中調用schedule_work函數, work便被添加到workqueue中, 等待處理.
工作隊列有著自己的處理線程, 這些work被延遲到這些線程中去處理. 處理過程只可能發生在這些背景工作執行緒中, 所以這裡可以睡眠.
核心預設啟動了一個工作隊列, 對應一組背景工作執行緒events/n(n代表處理器編號, 這樣的線程有n個). 驅動程式可以直接向這個工作隊列新增工作. 某些驅動程式還可能會建立並使用屬於自己的工作隊列.