來源：http://blog.chinaunix.net/uid-20528014-id-3068412.html
Linux中斷下半部處理有三種方式：軟中斷、tasklet、工作隊列。
曾經有人問我爲什麼要分這幾種，該怎麼用。當時用書上的東西蒙混了過去，但是自己明白自己實際上是不懂的。最近有時間了，於是試着整理一下linux的中斷處理機制，目的是起碼從原理上能夠說得通。
一、最簡單的中斷機制
最簡單的中斷機制就是像芯片手冊上講的那樣，在中斷向量表中填入跳轉到對應處理函數的指令，然後在處理函數中實現需要的功能。類似下圖：
這種方式在原來的單片機課程中常常用到，一些簡單的單片機系統也是這樣用。
它的好處很明顯，簡單，直接。
二、下半部
中斷處理函數所作的第一件事情是什麼？答案是屏蔽中斷（或者是什麼都不做，因爲常常是如果不清除IF位，就等於屏蔽中斷了），當然只屏蔽同一種中斷。之所以要屏蔽中斷，是因爲新的中斷會再次調用中斷處理函數，導致原來中斷處理現場的破壞。即，破壞了 interrupt context。
隨着系統的不斷複雜，中斷處理函數要做的事情也越來越多，多到都來不及接收新的中斷了。於是發生了中斷丟失，這顯然不行，於是產生了新的機制：分離中斷接收與中斷處理過程。中斷接收在屏蔽中斷的情況下完成；中斷處理在時能中斷的情況下完成，這部分被稱爲中斷下半部。
從上圖中看，只看int0的處理。Func0爲中斷接收函數。中斷只能簡單的觸發func0，而func0則能做更多的事情，它與funcA之間可以使用隊列等緩存機制。當又有中斷髮生時，func0被觸發，然後發送一箇中斷請求到緩存隊列，然後讓funcA去處理。
由於func0做的事情是很簡單的，所以不會影響int0的再次接收。而且在func0返回時就會使能int0，因此funcA執行時間再長也不會影響int0的接收。
三、軟中斷
下面看看linux中斷處理。作爲一個操作系統顯然不能任由每個中斷都各自爲政，統一管理是必須的。
我們不可中斷部分的共同部分放在函數do_IRQ中，需要添加中斷處理函數時，通過request_irq實現。下半部放在do_softirq中，也就是軟中斷，通過open_softirq添加對應的處理函數。
四、tasklet
舊事物跟不上歷史的發展時，總會有新事物出現。
隨着中斷數的不停增加，軟中斷不夠用了，於是下半部又做了進化。
軟中斷用輪詢的方式處理。假如正好是最後一種中斷，則必須循環完所有的中斷類型，才能最終執行對應的處理函數。顯然當年開發人員爲了保證輪詢的效率，於是限制中斷個數爲32個。
爲了提高中斷處理數量，順道改進處理效率，於是產生了tasklet機制。
Tasklet採用無差別的隊列機制，有中斷時才執行，免去了循環查表之苦。
總結下tasklet的優點：
（1）無類型數量限制；
（2）效率高，無需循環查表；
（3）支持SMP機制；
五、工作隊列
前面的機制不論如何折騰，有一點是不會變的。它們都在中斷上下文中。什麼意思？說明它們不可掛起。而且由於是串行執行，因此只要有一個處理時間較長，則會導致其他中斷響應的延遲。爲了完成這些不可能完成的任務，於是出現了工作隊列。工作隊列說白了就是一組內核線程，作爲中斷守護線程來使用。多箇中斷可以放在一個線程中，也可以每個中斷分配一個線程。
工作隊列對線程作了封裝，使用起來更方便。
因爲工作隊列是線程，所以我們可以使用所有可以在線程中使用的方法。
Tasklet其實也不一定是在中斷上下文中執行，它也有可能在線程中執行。
假如中斷數量很多，而且這些中斷都是自啓動型的（中斷處理函數會導致新的中斷產生），則有可能cpu一直在這裏執行中斷處理函數，會導致用戶進程永遠得不到調度時間。
爲了避免這種情況，linux發現中斷數量過多時，會把多餘的中斷處理放到一個單獨的線程中去做，就是ksoftirqd線程。這樣又保證了中斷不多時的響應速度，又保證了中斷過多時不會把用戶進程餓死。
問題是我們不能保證我們的tasklet或軟中斷處理函數一定會在線程中執行，所以還是不能使用進程才能用的一些方法，如放棄調度、長延時等。
六、使用方式總結
Request_irq掛的中斷函數要儘量簡單，只做必須在屏蔽中斷情況下要做的事情。
中斷的其他部分都在下半部中完成。
軟中斷的使用原則很簡單，永遠不用。它甚至都不算是一種正是的中斷處理機制，而只是tasklet的實現基礎。
工作隊列也要少用，如果不是必須要用到線程才能用的某些機制，就不要使用工作隊列。其實對於中斷來說，只是對中斷進行簡單的處理，大部分工作是在驅動程序中完成的。所以有什麼必要非使用工作隊列呢？
除了上述情況，就要使用tasklet。
即使是下半部，也只是作必須在中斷中要做的事情，如保存數據等，其他都交給驅動程序去做。
本文乃fireaxe原創，使用GPL發佈，可以自由拷貝，轉載。但轉載請保持文檔的完整性，並註明原作者及原鏈接。內容可任意使用，但對因使用該內容引起的後果不做任何保證。