❶ Linux內核中的軟中斷、tasklet和工作隊列詳解（超詳細~）
本文基於Linux2.6.32內核版本。
Linux內核中的軟中斷、tasklet和工作隊列是實現並發處理和非同步事件處理的重要機制。本文將詳細介紹這三者的基本概念、數據結構、API實現原理及實例應用。
軟中斷相關數據結構主要由struct softirq_action定義，其中void(*action)(struct softirq_action *)表示軟中斷觸發時的執行函數。
軟中斷的調度時機主要在中斷處理返回函數irq_exit中調用軟中斷。流程分為觸發和初始化兩個階段，具體實現見後續代碼實例。
圖示流程展示了軟中斷觸發和初始化的基本過程。
學習資源：推薦加入Linux內核技術交流群【891587639】，共享個人整理的優質學習資料。前100名進群將額外獲得大廠面試題。
深入學習路徑：關注內核資料直通車，獲取更多學習資源。
軟中斷處理流程包括軟中斷的觸發、執行及恢復。
tasklet相關數據結構定義了內核線程的任務，實現非同步任務調度。其核心API包括初始化、執行和取消。
工作隊列相關數據結構用於管理非同步任務的執行，包括任務隊列和執行器。其API實現包括任務的添加、執行和完成處理。
工作隊列的組織結構為鏈表形式，每個任務由結構體表示，包含執行函數、狀態等信息。
工作隊列的工作過程包括任務的添加、調度執行及狀態管理。具體實現細節包含#define preempt_count()、#define hardirq_count()、#define softirq_count()等宏，用於判斷當前是否處於中斷處理或軟體中斷處理過程中。
應用實例展示了如何使用工作隊列實現特定功能，如定時任務調度、設備驅動中的非同步事件處理等。
❷ Linux-怎麼理解軟中斷
中斷是系統用來響應硬體設備請求的一種機制，它會打斷進程的正常調度和執行，然後調用內核中的中斷處理程序來響應設備的請求。
你可能要問了，為什麼要有中斷呢？我可以舉個生活中的例子，讓感受一下中斷的魅力。
比如你訂了一份外賣，但是不確定外賣什麼時候送到，也沒有別的方法了解外賣的進度，但是，配送員送外賣是不等人的，到了你這兒沒人取的話，就直接走人了，所以你只能苦苦等著，時不時去門口看看外賣送到沒，而不能幹其他事情。
不過呢，如果在訂外賣的時候，你就跟配送員約定好，讓他送到後給你打個電話，那你就不用苦苦等待了，就可以去忙別的事情，直到電話一響，接電話、取外賣就可以了。
這里的「打電話」，其實就是一個中斷。沒接到電話的時候，你可以做其他的事情；只有接到了電話（也就是發生中斷），你才要進行另一個動作：取外賣。
這個例子你就可以發現， 中斷其實是一種非同步的事件處理機制，可以提高系統的並發處理能力。
由於中斷處理程序會打斷其他進程的運行，所以， 為了減少對正常進程運行調度的影響，中斷處理程序就需要盡可能快地運行。 如果中斷本身要做的事情不多，那麼處理起來也不會有太大問題；但如果中斷要處理的事情很多，中斷服務程序就有可能要運行很長時間。
特別是，中斷處理程序在響應中斷時，還會臨時關閉中斷。這就會導致上一次中斷處理完成之前，其他中斷都不能響應，也就是說中斷有可能會丟失。
那麼還是以取外賣為例。假如你訂了 2 份外賣，一份主食和一份飲料，並且是由 2 個不同的配送員來配送。這次你不用時時等待著，兩份外賣都約定了電話取外賣的方式。但是，問題又來了。
當第一份外賣送到時，配送員給你打了個長長的電話，商量發票的處理方式。與此同時，第二個配送員也到了，也想給你打電話。
但是很明顯，因為電話占線（也就是關閉了中斷響應），第二個配送員的電話是打不通的。所以，第二個配送員很可能試幾次後就走掉了（也就是丟失了一次中斷）。
如果你弄清楚了「取外賣」的模式，那對系統的中斷機制就很容易理解了。事實上，為了解決中斷處理程序執行過長和中斷丟失的問題，Linux 將中斷處理過程分成了兩個階段，也就是 上半部和下半部：
比如說前面取外賣的例子，上半部就是你接聽電話，告訴配送員你已經知道了，其他事兒見面再說，然後電話就可以掛斷了；下半部才是取外賣的動作，以及見面後商量發票處理的動作。
這樣，第一個配送員不會佔用你太多時間，當第二個配送員過來時，照樣能正常打通你的電話。
除了取外賣，我再舉個最常見的網卡接收數據包的例子，讓你更好地理解。
網卡接收到數據包後，會通過 硬體中斷 的方式，通知內核有新的數據到了。這時，內核就應該調用中斷處理程序來響應它。你可以自己先想一下，這種情況下的上半部和下半部分別負責什麼工作呢？
對上半部來說，既然是快速處理，其實就是要把網卡的數據讀到內存中，然後更新一下硬體寄存器的狀態（表示數據已經讀好了），最後再發送一個 軟中斷 信號，通知下半部做進一步的處理。
而下半部被軟中斷信號喚醒後，需要從內存中找到網路數據，再按照網路協議棧，對數據進行逐層解析和處理，直到把它送給應用程序。
所以，這兩個階段你也可以這樣理解：
實際上，上半部會打斷 CPU 正在執行的任務，然後立即執行中斷處理程序。而下半部以內核線程的方式執行，並且每個 CPU 都對應一個軟中斷內核線程，名字為 「ksoftirqd/CPU 編號」，比如說， 0 號 CPU 對應的軟中斷內核線程的名字就是 ksoftirqd/0。
不過要注意的是，軟中斷不只包括了剛剛所講的硬體設備中斷處理程序的下半部，一些內核自定義的事件也屬於軟中斷，比如內核調度和 RCU 鎖（Read-Copy Update 的縮寫，RCU 是 Linux 內核中最常用的鎖之一）等。
不知道你還記不記得，前面提到過的 proc 文件系統。它是一種內核空間和用戶空間進行通信的機制，可以用來查看內核的數據結構，或者用來動態修改內核的配置。其中：
運行下面的命令，查看 /proc/softirqs 文件的內容，你就可以看到各種類型軟中斷在不同 CPU 上的累積運行次數：
在查看 /proc/softirqs 文件內容時，你要特別注意以下這兩點。
第一，要注意軟中斷的類型，也就是這個界面中第一列的內容。從第一列你可以看到，軟中斷包括了 10 個類別，分別對應不同的工作類型。比如 NET_RX 表示網路接收中斷，而 NET_TX 表示網路發送中斷。
第二，要注意同一種軟中斷在不同 CPU 上的分布情況，也就是同一行的內容。正常情況下，同一種中斷在不同 CPU 上的累積次數應該差不多。比如這個界面中，NET_RX 在 CPU0 和 CPU1 上的中斷次數基本是同一個數量級，相差不大。
不過你可能發現，TASKLET 在不同 CPU 上的分布並不均勻。TASKLET 是最常用的軟中斷實現機制，每個 TASKLET 只運行一次就會結束 ，並且只在調用它的函數所在的 CPU 上運行。
因此，使用 TASKLET 特別簡便，當然也會存在一些問題，比如說由於只在一個 CPU 上運行導致的調度不均衡，再比如因為不能在多個 CPU 上並行運行帶來了性能限制。
另外，剛剛提到過，軟中斷實際上是以內核線程的方式運行的，每個 CPU 都對應一個軟中斷內核線程，這個軟中斷內核線程就叫做 ksoftirqd/CPU 編號。那要怎麼查看這些線程的運行狀況呢？
其實用 ps 命令就可以做到，比如執行下面的指令：
注意，這些線程的名字外面都有中括弧，這說明 ps 無法獲取它們的命令行參數（cmline）。一般來說，ps 的輸出中，名字括在中括弧里的，一般都是內核線程。
Linux 中的中斷處理程序分為上半部和下半部：
上半部對應硬體中斷，用來快速處理中斷。
下半部對應軟中斷，用來非同步處理上半部未完成的工作。
Linux 中的軟中斷包括網路收發、定時、調度、RCU 鎖等各種類型，可以通過查看 /proc/softirqs 來觀察軟中斷的運行情況。