做性能測試的必備知識系列，可以看下面連結的文章哦
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/softirqs ：提供了軟中斷的運作情況
/proc/interrupts ：提供了硬中斷的運作情況
從第一列可以看出，軟中斷包括了 10 個類别
比如：NET_RX 表示網絡接收中斷，而 NET_TX 表示網絡發送中斷
也就是同一行的内容
正常情況 下，同一種中斷在不同 CPU 上的累積次數應該差不多
比如：上面的，NET_RX 在 CPU0 和 CPU1 上的中斷次數基本是同一個數量級，相差不大
TASKLET 在不同 CPU 上的分布并不均勻
TASKLET 是最常用的軟中斷實作機制，每個 TASKLET 隻運作一次就會結束 ，并且隻在調用它的函數所在的 CPU 上運作
存在的問題： 由于隻在一個 CPU 上運作導緻的排程不均衡，再比如因為不能在多個 CPU 上并行運作帶來了性能限制
注意，這些線程的名字外面都有中括号，這說明 ps 無法擷取它們的指令行參數 （cmline）
一般來說，ps 的輸出中，名字括在中括号裡的，一般都是核心線程