軟中斷分析最近工作繁忙，沒有時間總結內核相關的一些東西。上次更新博客到了linux內核中斷子系統。這次總結一下軟中斷，也就是softirq。之后還會總結一些tasklet、工作隊列機制。

1.為什么要軟中斷

編寫驅動的時候，一個中斷產生之后，內核在中斷處理函數中可能需要完成很多工作。但是中斷處理函數的處理是關閉了中斷的。也就是說在響應中斷時，系統不能再次響應外部的其它中斷。這樣的后果會造成有可能丟失外部中斷。于是，linux內核設計出了一種架構，中斷函數需要處理的任務分為兩部分，一部分在中斷處理函數中執行，這時系統關閉中斷。另外一部分在軟件中斷中執行，這個時候開啟中斷，系統可以響應外部中斷。

關于軟件中斷的理論各種書籍都有介紹，不多敘述。而要真正體會軟件中斷的作用就必須從代碼的角度來分析。我們做工作時候講求的是professional，當一個人在某個領域一無所知的時候，我們稱他為小白，偶，非蘋果電腦。小白的腦子里充滿了各種問題。慢慢的當這些疑惑解釋完之后，小白就脫白了。此時，我們對這個領域的基本框架有了解，但這和professional還有一定的差距。再加以時日，逐漸融會貫通該領域才能達到專業的境界。

2. 什么時候觸發處理軟件中斷

說了這么多廢話，趕快步入正題。初識軟中斷，腦子里肯定有不少的疑問，首先就是軟件中斷在什么地方被觸發處理？這個問題的答案就是：一個硬件中斷處理完成之后。下面的函數在處理完硬件中斷之后推出中斷處理函數，在irq_exit中會觸發軟件中斷的處理。

這里要注意，invoke_softirq必須滿足兩個條件才能被調用到，一個就是不是在硬件中斷處理過程中或者在軟件中斷處理中，第二個就是必須有軟件中斷處于pending狀態。第二個好理解，有軟件中斷產生才去處理，沒有就不處理。第一個就不好理解了。

在linux系統的進程數據結構里，有這么一個數據結構

#define preempt_count()(current_thread_info()->preempt_count)，

利用preempt_count可以表示是否處于中斷處理或者軟件中斷處理過程中。

preempt_count的8～23位記錄中斷處理和軟件中斷處理過程的計數。如果有計數，表示系統在硬件中斷或者軟件中斷處理過程中。系統這么設計是為了避免軟件中斷在中斷嵌套中被調用，并且達到在單個CPU上軟件中斷不能被重入的目的。對于ARM架構的CPU不存在中斷嵌套中調用軟件中斷的問題，因為ARM架構的CPU在處理硬件中斷的過程中是關閉掉中斷的。只有在進入了軟中斷處理過程中之后才會開啟硬件中斷，如果在軟件中斷處理過程中有硬件中斷嵌套，也不會再次調用軟中斷，because硬件中斷是軟件中斷處理過程中再次進入的，此時preempt_count已經記錄了軟件中斷！對于其它架構的CPU，有可能在觸發調用軟件中斷前，也就是還在處理硬件中斷的時候，就已經開啟了硬件中斷，可能會發生中斷嵌套，在中斷嵌套中是不允許調用軟件中斷處理的。Why？我的理解是，在發生中斷嵌套的時候，表明這個時候是系統突發繁忙的時候，內核第一要務就是趕緊把中斷中的事情處理完成，退出中斷嵌套。避免多次嵌套，哪里有時間處理軟件中斷，所以把軟件中斷推遲到了所有中斷處理完成的時候才能觸發軟件中斷。

3. 軟件中斷的處理過程

之前我已經說到，軟中斷的一個很大的目的就是避免中斷處理中，處理的操作過多而丟失中斷。同時中斷還需要考慮到一件事情就是中斷處理過程過長就會影響系統響應時間。如果一個中斷處理一秒鐘，那你一定能感受到串口卡住的現象。從另外一方面說呢，我們又必須考慮中斷處理的操作一定的優先度，畢竟是硬件觸發的事務，關系到網絡、塊設備的效率問題。Linux內核就中斷方面就必須考慮平衡這三個方面的問題。而下面我要分析的__do_softirq函數就恰似在這三者之間打太極，游刃有余，面面俱到！

__do_softirq函數處理軟件中斷過程如下圖流程分析

4. 首先調用local_softirq_pending函數取得目前有哪些位存在軟件中斷

5. 調用__local_bh_disable關閉軟中斷，其實就是設置正在處理軟件中斷標記，在同一個CPU上使得不能重入__do_softirq函數

6. 重新設置軟中斷標記為0，set_softirq_pending重新設置軟中斷標記為0，這樣在之后重新開啟中斷之后硬件中斷中又可以設置軟件中斷位。

7. 開啟硬件中斷

8. 之后在一個循環中，遍歷pending標志的每一位，如果這一位設置就會調用軟件中斷的處理函數。在這個過程中硬件中斷是開啟的，隨時可以打斷軟件中斷。這樣保證硬件中斷不會丟失。

9. 之后關閉硬件中斷，查看是否又有軟件中斷處于pending狀態，如果是，并且在本次調用__do_softirq函數過程中沒有累計重復進入軟件中斷處理的次數超過10次，就可以重新調用軟件中斷處理。如果超過了10次，就調用wakeup_softirqd();喚醒內核的一個進程來處理軟件中斷。設立10次的限制，也是為了避免影響系統響應時間。

4. 處理軟中斷內核線程

之前我說到不能讓CPU長時間來處理中斷事務，這樣會影響系統的響應時間，嚴重影響用戶和系統之間的交互式體驗。所以在之前的__do_softirq中最多將循環執行10次，那么當執行了10次仍然有軟中斷在pending狀態，這個時候應該怎么處理呢？系統將喚醒一個軟件中斷處理的內核進程，在內核進程中處理pending中的軟件中斷。這里要注意，之前我們分析的觸發軟件中斷的位置其實是中斷上下文中，而在軟中斷的內核線程中實際已經是進程的上下文。

這里說的軟中斷上下文指的就是系統為每個CPU建立的ksoftirqd進程。

看完這個函數，我不得不佩服這個函數設計的精巧！而我更多的從中體會到其中蘊藏的一種做人的道理。那就是做人要霸道一點，太謙和太恭維不行，但是又不能橫行霸道，原則的問題要公平講理，一定的時候顧及別人的利益，好處不能一個人獨吞。這就跟下面ksoftirqd處理過程一樣，該狠的時候禁止搶占，其它進程別想調度到哦，但是自己占用CPU時間過長的話，也自覺的問一問是不是該釋放CPU給其它進程了。

下面我們就來分析一下這個處理過程怎么就體現了上面的這種說法呢？軟中斷的內核進程中主要有兩個大循環，外層的循環處理有軟件中斷就處理，沒有軟件中斷就休眠。內層的循環處理軟件中斷，并每循環一次都試探一次是否過長時間占據了CPU，需要調度釋放CPU給其它進程。具體的操作在注釋中做了解釋。