做效能測試的必備知識系列,可以看下面連結的文章哦
https://www.cnblogs.com/poloyy/category/1806772.html
前言
- 軟中斷(softirq)導致 CPU 使用率升高也是最常見的一種效能問題
- 所以軟中斷這個硬骨頭必須啃下去!
回憶下什麼是中斷
- 中斷是系統用來響應硬體裝置請求的一種機制
- 它會打斷程式的正常排程和執行
- 然後呼叫核心中的中斷處理程式來響應硬體裝置的請求
場景類比,加深印象
比如說你訂了一份外賣,但是不確定外賣什麼時候送到,也沒有別的方法瞭解外賣的進度, 但是,配送員送外賣是不等人的,到了你這兒沒人取的話,就直接走人了;所以你只能苦苦等著,時不時去門口看看外賣送到沒,而不能幹其他事情;不過呢,如果在訂外賣的時候,你就跟配送員約定好,讓他送到後給你打個電話,那你就不用苦苦等待了,就可以去忙別的事情,直到電話一響,接電話、取外賣就可以了、
- 打電話:其實就是一箇中斷,沒接到電話的時候,你可以做其他的事情
- 只有接到了電話(也就是發生中斷),你才要進行另一個動作:取外賣
中斷的優勢
一種非同步的事件處理機制,可以提高系統的併發處理能力
中斷執行時間短
- 由於中斷處理程式會打斷其他程式的執行,為了減少對正常程式執行排程的影響,中斷處理程式就需要儘可能快地執行
- 如果中斷要處理的事情很多,中斷服務程式就有可能要執行很長時間
中斷處理程式在響應中斷
會臨時關閉中斷。這就會導致上一次中斷處理完成之前,其他中斷都不能響應,也就是說中斷有可能會丟失
響應中斷場景類比
假如你訂了 2 份外賣,一份主食和一份飲料,並且是由 2 個不同的配送員來配送。這次你不用時時等待著,兩份外賣都約定了電話取外賣的方式。但是,問題又來了,當第一份外賣送到時,配送員給你打了個長長的電話,商量發票的處理方式。與此同時,第 二個配送員也到了,也想給你打電話。 但是很明顯,因為電話佔線(也就是關閉了中斷響應),第二個配送員的電話是打不通的。 所以,第二個配送員很可能試幾次後就走掉了(也就是丟失了一次中斷)
軟中斷
中斷處理過程分割
- 為了解決中斷處理程式執行過長和中斷丟失的問題,Linux 會將中斷處理過程分成兩個階段,也就是上半部和下半部
- 上半部:快速處理中斷,它在中斷禁止模式下執行,主要處理跟硬體緊密相關的或時間敏感的工作
- 下半部:延遲處理上半部未完成的工作,通常以核心執行緒的方式執行
承上啟下
- 上面說到的響應中斷場景
- 上半部就是你接聽電話,告訴配送員你已經知道了,其他事兒見面再說,然後電話就可以結束通話了
- 下半部才是取外賣的動作,以及見面後商量發票處理的動 作。
網路卡接收資料包的栗子
網路卡接收到資料包後,會通過硬體中斷的方式,通知核心有新的資料到了。這時,核心就應該呼叫中斷處理程式來響應它
上半部
- 快速處理
- 首先,要把網路卡的資料讀到記憶體中
- 然後,更新一下硬體暫存器的狀態(表示資料已經讀好了)
- 最後,再傳送一個軟中斷訊號,通知下半部做進一步的處理
下半部
- 被軟中斷訊號喚醒
- 需要從記憶體中找到網路資料,再按照網路協議棧,對資料進行逐層解析和處理,直到把它送給應用程式
總結
上半部
- 直接處理硬體請求,也就是硬中斷
- 特點:快速執行
- 會打斷 CPU 正在執行的任務,然後立即執行中斷處理程式
下半部
- 由核心觸發,也就是軟中斷
- 特點:延遲執行
- 以核心執行緒的方式執行,並且每個 CPU 都對應一個軟中斷核心執行緒,名字為 “ksoftirqd/CPU 編號”,比如說, 0 號 CPU 對應的軟中斷核心執行緒的名字就是 ksoftirqd/0
- 不只包括了硬體裝置中斷處理程式的下半部,一些核心自定義的事件也屬於軟中斷,網路收發、定時、排程、RCU 鎖等各種型別
- 核心排程和 RCU 鎖(Read-Copy Update), RCU 是 Linux 核心中最常用的鎖之一
檢視軟中斷和核心執行緒
proc 檔案系統
它是一種核心空間和使用者空間進行通訊的機制,可以用來檢視核心的資料結構,或者用來動態修改核心的配置
- /proc/softirqs :提供了軟中斷的執行情況
- /proc/interrupts :提供了硬中斷的執行情況
檢視軟中斷檔案內容
$ cat /proc/softirqs CPU0 CPU1 HI: 0 0 TIMER: 811613 1972736 NET_TX: 49 7 NET_RX: 1136736 1506885 BLOCK: 0 0 IRQ_POLL: 0 0 TASKLET: 304787 3691 SCHED: 689718 1897539 HRTIMER: 0 0 RCU: 1330771 1354737
注意軟中斷的型別
- 從第一列可以看出,軟中斷包括了 10 個類別
- 比如:NET_RX 表示網路接收中斷,而 NET_TX 表示網路傳送中斷
注意同一種軟中斷在不同 CPU 上的分佈情況
- 也就是同一行的內容
- 正常情況 下,同一種中斷在不同 CPU 上的累積次數應該差不多
- 比如:上面的,NET_RX 在 CPU0 和 CPU1 上的中斷次數基本是同一個數量級,相差不大
TASKLET
- TASKLET 在不同 CPU 上的分佈並不均勻
- TASKLET 是最常用的軟中斷實現機制,每個 TASKLET 只執行一次就會結束 ,並且只在呼叫它的函式所在的 CPU 上執行
- 存在的問題: 由於只在一個 CPU 上執行導致的排程不均衡,再比如因為不能在多個 CPU 上並行執行帶來了效能限制
檢視軟中斷執行緒
ps aux | grep softirq
- 注意,這些執行緒的名字外面都有中括號,這說明 ps 無法獲取它們的命令列引數 (cmline)
- 一般來說,ps 的輸出中,名字括在中括號裡的,一般都是核心執行緒