linux中斷處理原理分析

2021-07-10 02:19:32 字數 2931 閱讀 1603

部落格:fireaxe.blog.chinaunix.net

tasklet作為一種新機制,顯然可以承擔更多的優點。正好這時候smp越來越火了,因此又在tasklet中加入了smp機制,保證同種中斷只能在乙個cpu上執行。在軟中斷時代,顯然沒有這種考慮。因此同一種中斷可以在兩個cpu上同時執行,很可能造成衝突。

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機制;

五、工作佇列

前面的機制不論如何折騰,有一點是不會變的。它們都在中斷上下文中。什麼意思?說明它們不可掛起。而且由於是序列執行,因此只要有乙個處理時間較長,則會導致其他中斷響應的延遲。為了完成這些不可能完成的任務,於是出現了工作佇列。工作佇列說白了就是一組核心執行緒,作為中斷守護執行緒來使用。多個中斷可以放在乙個執行緒中,也可以每個中斷分配乙個執行緒。

工作佇列對執行緒作了封裝,使用起來更方便。

假如中斷數量很多,而且這些中斷都是自啟動型的(中斷處理函式會導致新的中斷產生),則有可能cpu一直在這裡執行中斷處理函式,會導致使用者程序永遠得不到排程時間。

為了避免這種情況,linux發現中斷數量過多時,會把多餘的中斷處理放到乙個單獨的執行緒中去做,就是ksoftirqd執行緒。這樣又保證了中斷不多時的響應速度,又保證了中斷過多時不會把使用者程序餓死。

六、使用方式總結

request_irq掛的中斷函式要盡量簡單,只做必須在遮蔽中斷情況下要做的事情。

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

軟中斷的使用原則很簡單,永遠不用。它甚至都不算是一種正是的中斷處理機制,而只是tasklet的實現基礎。

工作佇列也要少用,如果不是必須要用到執行緒才能用的某些機制,就不要使用工作佇列。其實對於中斷來說,只是對中斷進行簡單的處理,大部分工作是在驅動程式中完成的。所以有什麼必要非使用工作佇列呢?

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

即使是下半部,也只是作必須在中斷中要做的事情,如儲存資料等,其他都交給驅動程式去做。

補充:

從上述過程以及tasklet的設計可以看出,tasklet整體是這麼執行的:驅動應該在其硬中斷處理函式的莫為呼叫tasklet_schedule()介面啟用該taskle,核心經常呼叫do_softirq()執行軟中斷,通過softirq執行tasket,如下圖所示。圖中灰色部分為禁止硬中斷部分,為保護軟中斷pending點陣圖和tasklet_vec鍊錶陣列,count的改變均為原子操作,count確保smp架構下同時只有乙個cpu在執行該tasklet:

部落格:fireaxe.blog.chinaunix.net

linux中斷處理原理分析

1 中斷概念 為什麼需要中斷?1 外設的處理速度一般慢於cpu 2 cpu不能一直等待外部事件 所以裝置必須有一種方法來通知cpu它的工作進度,這種方法就是中斷。2 中斷實現 在linux驅動程式中,為裝置實現乙個中斷包含兩個步驟 1 向核心註冊中斷 2 實現中斷處理函式 3 中斷註冊 reques...

linux中斷處理原理分析

首先需要了解一下中斷的概念 乙個 中斷 僅僅是乙個訊號,當硬體需要獲得處理器對它的關注時,就可以傳送這個訊號。核心維護了乙個中斷訊號線的登錄檔,該登錄檔類似於i o埠的登錄檔。模組在使用中斷前要先請求乙個中斷通道 或中斷請求irq 然後在使用後釋放該通道。用到的api就是request irq 以及...

linux中斷處理原理分析

tasklet作為一種新機制,顯然可以承擔更多的優點。正好這時候smp越來越火了,因此又在tasklet中加入了smp機制,保證同種中斷只能在乙個cpu上執行。在軟中斷時代,顯然沒有這種考慮。因此同一種中斷可以在兩個cpu上同時執行,很可能造成衝突。linux中斷下半部處理有三種方式 軟中斷 tas...