歡迎來到Linux教程網
Linux教程網
Linux教程網
Linux教程網
Linux教程網 >> Linux編程 >> Linux編程 >> 理解 Linux 內核的軟中斷

理解 Linux 內核的軟中斷

日期:2017/3/1 9:29:29   编辑:Linux編程

軟中斷介紹

把可以延遲的處理從硬中斷處理程序獨立出來,這樣這個處理可以在開中斷的情況下運行,這個處理就是軟中斷。可見,軟中斷的這種脫離可以大大縮短硬中斷的響應時間,對於很多實時應用來說及其重要。

我們本文只談軟中斷,至於tasklet、workqueue等我們以後再談。我們在講述軟中斷流程(參考linux kernel 4.0)時會嘗試深入理解其中的各個細節之處,分享我們自己的理解(如果不正,還望指出,謝謝)。

(題圖來自:techvark.com)

軟中斷數據結構的定義

軟中斷目前有10(由NR_SOFTIRQS定義)個,通過softirq_vec[NR_SOFTIRQS]數組來管理這些軟中斷,全部cpu共用。

軟中斷的注冊

通過open_softirq()將具體的軟中斷處理函數和軟中斷編號綁定。如網絡系統注冊了收發包的軟中斷處理函數:

  1. open_softirq(NET_TX_SOFTIRQ, net_tx_action);
  2. open_softirq(NET_RX_SOFTIRQ, net_rx_action);

軟中斷的激活

每個cpu都有一個32bit的位圖(即__softirq_pending)來維護本cpu上的軟中斷是否激活。

  1. typedefstruct{
  2. unsignedint __softirq_pending;
  3. #ifdef CONFIG_SMP
  4. unsignedint ipi_irqs[NR_IPI];
  5. #endif
  6. } ____cacheline_aligned irq_cpustat_
  7. irq_cpustat_t irq_stat[NR_CPUS] ____cacheline_aligned;

軟中斷的激活時機之一:irq_exit

irq_exit函數裡可能會激活軟中斷,激活條件是:

不在硬中斷裡並且不在軟中斷裡並且本cpu的__softirq_pending中有置位。

  1. if(!in_interrupt()&& local_softirq_pending())
  2. invoke_softirq();

由這個條件,我們可以知道,軟中斷和硬中斷在這裡是同等對待(在in_interrupt裡)的,體現都是中斷處理這一個本質。不能在硬中斷裡的條件,表明必須優先性,必須硬中斷全部處理完,才考慮軟中斷;不能在軟中斷裡的條件,表明屏蔽了軟中斷的嵌套。

invoke_softirq函數的處理是,要麼(先喚醒ksoftirqd)將軟中斷交由ksoftirqd專門線程處理,要麼直接調用__do_softirq即時處理(當然,即時處理要區分是在哪個棧上:是當前棧上還是在獨立的軟中斷棧上)。

我們看看即時處理這個流程。local_softirq_pending前肯定會清除preempt_count中的硬中斷位,如果此時preempt_count裡沒有軟中斷位則可以被搶占(即時關閉硬中斷)。在進入到__do_softirq處理各個軟中斷期間,肯定是禁止搶占了。在硬(軟)中斷上下文裡的搶占是眾所周知不被允許的:會讓被中斷的進程執行時間不確定,也是不公平的(也就是說,不要在硬中斷和軟中斷的處理中有調度離開的意向)。

軟中斷的激活時機之二:raise_softirq

網卡收包方式從非NAPI進化到NAPI方式,就充分展示了軟中斷的優點:把收報任務最大程度地交給軟中斷處理,最大程度簡化硬中斷處理。這種進化,我們以後再講。

raise_softirq函數會調用__raise_softirq_irqoff函數,在指定cpu的__softirq_pending位圖上置位相應的軟中斷。raise_softirq_irqoff函數和raise_softirq函數的區別是關中斷的操作是否已經完成了。置位位圖是一個競爭操作,所有硬中斷裡都可能做,所以得保證在關中斷的情況下完成。

軟中斷的激活之三:ksoftirqd

每個cpu都有一個ksoftirqd線程在軟中斷量大時專門處理軟中斷:

  1. DEFINE_PER_CPU(struct task_struct *, ksoftirqd);

ksoftirqd線程的核心函數run_ksoftirqd的(循環)處理是:關中斷看本cpu的__softirq_pending的置位情況,如有則執行__do_softirqd(),執行完開中斷)。這個執行很順暢,因為是在該線程自己的棧上,不會有影響用戶進程的問題。

這裡有個疑問,此處以前是關搶占保護,現在是關中斷的保護了(參考2012年的patch 3e339b,softirq: Use hotplugthread infrastructure)?我們的理解是:關搶占的保護方式,會讓後續更多的軟中斷由ksoftirqd處理,不符合ksoftirqd的輔助地位。就處理軟中斷的地位而言,應該是irq_exit的為主,ksoftirqd的為輔。)

ksoftirqd裡也可以看到,在執行軟中斷前是可以被搶占的,但是一旦開始執行就不能被搶占了(和上面的調度之一:irq_exit中的講述的思想是一致的)。就是說,軟中斷和硬中斷的處理思想是一致的:執行期間不允許發生調度!

上述不能搶占的原因其實就是類似事務性的一個原則:一旦開始不能停止。另外一個原因是,執行的是用戶自定義的硬(軟)中斷程序,操作具有不確定性,如果讓這些操作期間具有調度可能,則會脫離內核的控制范圍。

軟中斷的激活之四:其他地方

比如netif_rx_ni(),執行do_softirq前關搶占,不能在執行軟中斷期間調度。

軟中斷的激活之五:local_bh_enable

  1. if(unlikely(!in_interrupt()&& local_softirq_pending()))
  2. do_softirq();

想想,如果異常和軟中斷有共享數據的話,異常處理走到此共享數據的臨界區時需要關軟中斷,但不需要關硬中斷。那麼當走完臨界區時,需要開軟中斷,此時就是一個激活時機(看preempt_count了,其實可能也是一個搶占時機)。

用“激活”而不是“調用”的原因是外圍處理僅修改本cpu的__softirq_pending位圖,最後由核心機制(比如ksoftirqd、能通過in_interrupt檢查的軟中斷處理)真正處理,而這就是軟中斷的理念:讓硬中斷(或者其它)更快執行,所以不會采用直接調用的方式。

“激活”的原則是誰激活,誰處理,哪個cpu上的硬中斷帶來的軟中斷就由哪個cpu處理(或者說,歸屬cpu是軟中斷跟著硬中斷走)。這樣,充分發揮smp的優勢,均衡到各個cpu上。至於硬中斷和cpu之間的關系,我們以後講到硬中斷時再討論。每個cpu維護自己的軟中斷機制就行了,各個cpu是互不相關的。注意,還是有相關性的:各個cpu並行處理同一類型的軟中斷時,該類型軟中斷處理需要為共享數據做保護,這是軟中斷可重入性需要付出的代價。

軟中斷核心函數處理之do_softirq

do_softirq先檢查軟中斷重入條件:必須不在硬中斷裡並且不在軟中斷裡,符合條件之後就可以開始做如下的軟中斷處理了:

  1. pending = local_softirq_pending();
  2. if(pending)
  3. __do_softirq();

這個處理是在關中斷的保護下完成的,畢竟軟中斷和硬中斷本質上是一樣的,都是中斷體系的(當然,進入到硬/軟中斷內部再開則另當別論了)。也可以看到,局部變量pending沒有傳入__do_softirq內部,所以此處僅是判斷,不是使用,此處判斷值和內部使用值可能有差異,位圖中置位位數會少一些。

我們再深究一下這個檢查條件。我們的理解是:

這個條件達到了兩個效果:同一個cpu上的軟中斷不嵌套;嵌套硬中斷中不處理軟中斷。就同一個cpu而言,__do_softirq函數的執行是串行的,非重入的(do_softirq函數可以說是可重入的);就多個cpu而言,__do_softirq函數是可重入的,即使是同一個類型的軟中斷。也就是說,軟中斷通過這個檢查條件做到了本cpu上的軟中斷處理串行化,當然,多cpu之間的還是並行的,所以同一類型軟中斷處理還是需要保護自己的相關共享數據結構的。

軟中斷核心函數處理之__do_softirq

__do_softirq函數處理是盡量(雖然可能還是執行不完)執行所有被激活的軟中斷(由本cpu上的__softirq_pending位圖標識)處理。我們分三個階段分析。

准備處理階段:關閉軟中斷(效果是讓上面提到的檢查條件為真,從而達到禁止本cpu上的軟中斷嵌套的目的)。

核心處理階段:關硬中斷,獲得本cpu的__softirq_pending位圖並存儲起來,清空位圖,開硬中斷(僅在讀寫位圖時需要關硬中斷,防止其它硬中斷同時操作)。執行本cpu的所有軟中斷(由存儲起來的位圖獲得)。這個核心處理是個循環,最多10次(MAX_SOFTIRQ_RESTART),畢竟此時用的是用戶進程的棧,不能借用太久。退出循環的條件是:總時間超出或者被搶占(開中斷就會有被搶占)或者達到10次了。

結尾處理階段:關硬中斷,開軟中斷。

另外,如果10次循環都解決不完軟中斷,說明期間發生的硬中斷很多,帶來的額外的軟中斷也很多。那麼就不繼續影響借用的用戶進程棧了,直接交給專門的ksoftirqd內核線程處理。這也就說明了循環的含義:處理軟中斷期間時還會進入新的硬中斷,從而帶進新的軟中斷(當然,僅僅是在本cpu的__softirq_pending上置位,不會有實際處理),所以需要反復去處理(處理的目標很明確,就是要清空本cpu上的__softirq_pending位圖)。

再看看那個防止軟中斷嵌套的流程。關軟中斷中肯定有一句原子地加1的關鍵語句,如果當前內核路徑A在該原子操作之前被另一個內核路徑B打斷,則B執行完硬中斷和軟中斷後,返回到A的此處,A接著執行該原子操作,之後的軟中斷處理應該是空轉,因為肯定已經被B處理完了。如果在該原子操作之後被B打斷,則B執行完硬中斷,不會執行自己的軟中斷而是會直接退出(因為軟中斷嵌套了),返回到A的此處,A接著執行,這次A除了處理自己軟中斷,還會額外地處理B的軟中斷。

對於preempt_count中的軟中斷位,由上述可以知道,它的作用有兩個:防止軟中斷在單cpu上嵌套;保證了在執行軟中斷期間不被搶占。

最後,還得重復一句:這裡講的__do_softirq函數都是在一個cpu上的處理,多個cpu上的並行是不受任何控制的。

總結

關於中斷的時序貌似很復雜,但其實都逃不過兩個原則:硬中斷會打斷硬中斷(當然是不同類型的);硬中斷會打斷軟中斷(同樣地:軟中斷不會打斷硬中斷,軟中斷也不會打斷軟中斷)。所有貌似復雜的時序其實都只是這兩個的疊加而已。

作者:計算機學習微信公眾號(jsj_xx)

Copyright © Linux教程網 All Rights Reserved