linux中斷處理原理分析

　　Tasklet作為一種新機制，顯然可以承擔更多的優(yōu)點(diǎn)。正好這時(shí)候SMP越來(lái)越火了，因此又在tasklet中加入了SMP機制，保證同種中斷只能在一個(gè)cpu上執行。在軟中斷時(shí)代，顯然沒(méi)有這種考慮。因此同一種中斷可以在兩個(gè)cpu上同時(shí)執行，很可能造成沖突。

　　Linux中斷下半部處理有三種方式：軟中斷、tasklet、工作隊列。

　　曾經(jīng)有人問(wèn)我為什么要分這幾種，該怎么用。當時(shí)用書(shū)上的東西蒙混了過(guò)去，但是自己明白自己實(shí)際上是不懂的。最近有時(shí)間了，于是試著(zhù)整理一下linux的中斷處理機制，目的是起碼從原理上能夠說(shuō)得通。

　　一、最簡(jiǎn)單的中斷機制

　　最簡(jiǎn)單的中斷機制就是像芯片手冊上講的那樣，在中斷向量表中填入跳轉到對應處理函數的指令，然后在處理函數中實(shí)現需要的功能。類(lèi)似下圖：  

　　這種方式在原來(lái)的單片機課程中常常用到，一些簡(jiǎn)單的單片機系統也是這樣用。

　　它的好處很明顯，簡(jiǎn)單，直接。

　　二、下半部

　　中斷處理函數所作的第一件事情是什么?答案是屏蔽中斷(或者是什么都不做，因為常常是如果不清除IF位，就等于屏蔽中斷了)，當然只屏蔽同一種中斷。之所以要屏蔽中斷，是因為新的中斷會(huì )再次調用中斷處理函數，導致原來(lái)中斷處理現場(chǎng)的破壞。即，破壞了 interrupt context。

　　隨著(zhù)系統的不斷復雜，中斷處理函數要做的事情也越來(lái)越多，多到都來(lái)不及接收新的中斷了。于是發(fā)生了中斷丟失，這顯然不行，于是產(chǎn)生了新的機制：分離中斷接收與中斷處理過(guò)程。中斷接收在屏蔽中斷的情況下完成;中斷處理在時(shí)能中斷的情況下完成，這部分被稱(chēng)為中斷下半部。

　　從上圖中看，只看int0的處理。Func0為中斷接收函數。中斷只能簡(jiǎn)單的觸發(fā)func0，而func0則能做更多的事情，它與funcA之間可以使用隊列等緩存機制。當又有中斷發(fā)生時(shí)，func0被觸發(fā)，然后發(fā)送一個(gè)中斷請求到緩存隊列，然后讓funcA去處理。

　　由于func0做的事情是很簡(jiǎn)單的，所以不會(huì )影響int0的再次接收。而且在func0返回時(shí)就會(huì )使能int0，因此funcA執行時(shí)間再長(cháng)也不會(huì )影響int0的接收。

　　三、軟中斷

　　下面看看linux中斷處理。作為一個(gè)操作系統顯然不能任由每個(gè)中斷都各自為政，統一管理是必須的。

　　我們不可中斷部分的共同部分放在函數do_IRQ中，需要添加中斷處理函數時(shí)，通過(guò)request_irq實(shí)現。下半部放在do_softirq中，也就是軟中斷，通過(guò)open_softirq添加對應的處理函數。

　　四、tasklet

　　舊事物跟不上歷史的發(fā)展時(shí)，總會(huì )有新事物出現。

　　隨著(zhù)中斷數的不停增加，軟中斷不夠用了，于是下半部又做了進(jìn)化。

　　軟中斷用輪詢(xún)的方式處理。假如正好是最后一種中斷，則必須循環(huán)完所有的中斷類(lèi)型，才能最終執行對應的處理函數。顯然當年開(kāi)發(fā)人員為了保證輪詢(xún)的效率，于是限制中斷個(gè)數為32個(gè)。

　　為了提高中斷處理數量，順道改進(jìn)處理效率，于是產(chǎn)生了tasklet機制。

　　Tasklet采用無(wú)差別的隊列機制，有中斷時(shí)才執行，免去了循環(huán)查表之苦。

　　總結下tasklet的優(yōu)點(diǎn)：

　　(1)無(wú)類(lèi)型數量限制;

　　(2)效率高，無(wú)需循環(huán)查表;

　　(3)支持SMP機制;

　　五、工作隊列

　　前面的機制不論如何折騰，有一點(diǎn)是不會(huì )變的。它們都在中斷上下文中。什么意思?說(shuō)明它們不可掛起。而且由于是串行執行，因此只要有一個(gè)處理時(shí)間較長(cháng)，則會(huì )導致其他中斷響應的延遲。為了完成這些不可能完成的任務(wù)，于是出現了工作隊列。工作隊列說(shuō)白了就是一組內核線(xiàn)程，作為中斷守護線(xiàn)程來(lái)使用。多個(gè)中斷可以放在一個(gè)線(xiàn)程中，也可以每個(gè)中斷分配一個(gè)線(xiàn)程。

　　工作隊列對線(xiàn)程作了封裝，使用起來(lái)更方便。

　　因為工作隊列是線(xiàn)程，所以我們可以使用所有可以在線(xiàn)程中使用的方法。

　　Tasklet其實(shí)也不一定是在中斷上下文中執行，它也有可能在線(xiàn)程中執行。

　　假如中斷數量很多，而且這些中斷都是自啟動(dòng)型的(中斷處理函數會(huì )導致新的中斷產(chǎn)生)，則有可能cpu一直在這里執行中斷處理函數，會(huì )導致用戶(hù)進(jìn)程永遠得不到調度時(shí)間。

　　為了避免這種情況，linux發(fā)現中斷數量過(guò)多時(shí)，會(huì )把多余的中斷處理放到一個(gè)單獨的線(xiàn)程中去做，就是ksoftirqd線(xiàn)程。這樣又保證了中斷不多時(shí)的響應速度，又保證了中斷過(guò)多時(shí)不會(huì )把用戶(hù)進(jìn)程餓死。

　　問(wèn)題是我們不能保證我們的tasklet或軟中斷處理函數一定會(huì )在線(xiàn)程中執行，所以還是不能使用進(jìn)程才能用的一些方法，如放棄調度、長(cháng)延時(shí)等。

　　六、使用方式總結

　　Request_irq掛的中斷函數要盡量簡(jiǎn)單，只做必須在屏蔽中斷情況下要做的事情。

　　中斷的其他部分都在下半部中完成。

　　軟中斷的使用原則很簡(jiǎn)單，永遠不用。它甚至都不算是一種正是的中斷處理機制，而只是tasklet的實(shí)現基礎。

　　工作隊列也要少用，如果不是必須要用到線(xiàn)程才能用的某些機制，就不要使用工作隊列。其實(shí)對于中斷來(lái)說(shuō)，只是對中斷進(jìn)行簡(jiǎn)單的處理，大部分工作是在驅動(dòng)程序中完成的。所以有什么必要非使用工作隊列呢?

　　除了上述情況，就要使用tasklet。

　　即使是下半部，也只是作必須在中斷中要做的事情，如保存數據等，其他都交給驅動(dòng)程序去做。