【原創】Linux中斷子系統（三）-softirq和tasklet
阿新 • • 發佈：2020-06-14
# 背景
- `Read the fucking source code!` --By 魯迅
- `A picture is worth a thousand words.` --By 高爾基
說明：
1. Kernel版本：4.14
2. ARM64處理器，Contex-A53，雙核
3. 使用工具：Source Insight 3.5， Visio
# 1. 概述
中斷子系統中有一個重要的設計機制，那就是`Top-half和Bottom-half`，將緊急的工作放置在`Top-half`中來處理，而將耗時的工作放置在`Bottom-half`中來處理，這樣確保`Top-half`能儘快完成處理，那麼為什麼需要這麼設計呢？看一張圖就明白了：
- ARM處理器在進行中斷處理時，處理器進行異常模式切換，此時會將中斷進行關閉，處理完成後再將中斷開啟；
- 如果中斷不分上下半部處理，那麼意味著只有等上一個中斷完成處理後才會開啟中斷，下一個中斷才能得到響應。當某個中斷處理處理時間較長時，很有可能就會造成其他中斷丟失而無法響應，這個顯然是難以接受的，比如典型的時鐘中斷，作為系統的脈搏，它的響應就需要得到保障；
- 中斷分成上下半部處理可以提高中斷的響應能力，在上半部處理完成後便將中斷開啟（通常上半部處理越快越好），這樣就可以響應其他中斷了，等到中斷退出的時候再進行下半部的處理；
- 中斷的`Bottom-half`機制，包括了`softirq`、`tasklet`、`workqueue`、以及前文中提到過的中斷執行緒化處理等，其中`tasklet`又是基於`softirq`來實現的，這也是本文討論的主題；
在中斷處理過程中，離不開各種上下文的討論，瞭解不同上下文的區分有助於中斷處理的理解，所以，還是來一張老圖吧：
- `task_struct`結構體中的`thread_info.preempt_count`用於記錄當前任務所處的`context`狀態；
- `PREEMPT_BITS`：用於記錄禁止搶佔的次數，禁止搶佔一次該值就加1，使能搶佔該值就減1；
- `SOFTIRQ_BITS`：用於同步處理，關掉下半部的時候加1，開啟下半部的時候減1；
- `HARDIRQ_BITS`：用於表示處於硬體中斷上下文中；
前戲結束了，直奔主題吧。
# 2. softirq
## 2.1 初始化
`softirq`不支援動態分配，Linux kernel提供了靜態分配，關鍵的結構體描述如下，可以類比硬體中斷來理解：
```c
/* 支援的軟中斷型別，可以認為是軟中斷號， 其中從上到下優先順序遞減 */
enum
{
HI_SOFTIRQ=0, /* 最高優先順序軟中斷 */
TIMER_SOFTIRQ, /* Timer定時器軟中斷 */
NET_TX_SOFTIRQ, /* 傳送網路資料包軟中斷 */
NET_RX_SOFTIRQ, /* 接收網路資料包軟中斷 */
BLOCK_SOFTIRQ, /* 塊裝置軟中斷 */
IRQ_POLL_SOFTIRQ, /* 塊裝置軟中斷 */
TASKLET_SOFTIRQ, /* tasklet軟中斷 */
SCHED_SOFTIRQ, /* 程序排程及負載均衡的軟中斷 */
HRTIMER_SOFTIRQ, /* Unused, but kept as tools rely on thenumbering. Sigh! */
RCU_SOFTIRQ, /* Preferable RCU should always be the last softirq， RCU相關的軟中斷 */
NR_SOFTIRQS
};
/* 軟體中斷描述符，只包含一個handler函式指標 */
struct softirq_action {
void (*action)(struct softirq_action *);
};
/* 軟中斷描述符表，實際上就是一個全域性的陣列 */
static struct softirq_action softirq_vec[NR_SOFTIRQS] __cacheline_aligned_in_smp;
/* CPU軟中斷狀態描述，當某個軟中斷觸發時，__softirq_pending會置位對應的bit */
typedef struct {
unsigned int __softirq_pending;
unsigned int ipi_irqs[NR_IPI];
} ____cacheline_aligned irq_cpustat_t;
/* 每個CPU都會維護一個狀態資訊結構 */
irq_cpustat_t irq_stat[NR_CPUS] ____cacheline_aligned;
/* 核心為每個CPU都建立了一個軟中斷處理核心執行緒 */
DEFINE_PER_CPU(struct task_struct *, ksoftirqd);
```
來一張圖吧：
- `softirq_vec[]`陣列，類比硬體中斷描述符表`irq_desc[]`，通過軟中斷號可以找到對應的`handler`進行處理，比如圖中的`tasklet_action`就是一個實際的`handler`函式；
- 軟中斷可以在不同的CPU上並行執行，在同一個CPU上只能序列執行；
- 每個CPU維護`irq_cpustat_t`狀態結構，當某個軟中斷需要進行處理時，會將該結構體中的`__softirq_pending`欄位或上`1UL << XXX_SOFTIRQ`；
## 2.2 流程分析
### 2.2.1 軟中斷註冊
中斷處理流程中裝置驅動通過`request_irq/request_threaded_irq`介面來註冊中斷處理函式，而在軟中斷處理流程中，通過`open_softirq`介面來註冊，由於它實在是太簡單了，我忍不住想把程式碼貼上來：
```c
void open_softirq(int nr, void (*action)(struct softirq_action *))
{
softirq_vec[nr].action = action;
}
```
也就是將軟中斷描述符表中對應描述符的`handler`函式指標指向對應的函式即可，以便軟中斷到來時進行回撥。
那麼，問題來了，什麼時候進行軟中斷函式回撥呢？
### 2.2.2 軟中斷執行之一：中斷處理後
先看第一種情況，用圖片來回答問題：
- [Linux中斷子系統（二）-通用框架處理](https://www.cnblogs.com/LoyenWang/p/13052677.html)文章中講述了整個中斷處理流程，在接收到中斷訊號後，處理器進行異常模式切換，並跳轉到異常向量表處進行執行，關鍵的流程為：`el0_irq->irq_handler->handle_arch_irq(gic->handle_irq)->handle_domain_irq->__handle_domain_irq`；
- 在`__handle_domain_irq`函式中，`irq_enter`和`irq_exit`分別用於來標識進入和離開硬體中斷上下文處理，這個從`preempt_count_add/preempt_count_sub`來操作`HARDIRQ_OFFSET`可以看出來，這也對應到了上文中的Context描述圖；
- 在離開硬體中斷上下文後，如果`!in_interrupt() && local_softirq_pending`為真，則進行軟中斷處理。這個條件有兩個含義：1）`!in_interrupt()`表明不能處在中斷上下文中，這個範圍包括`in_nmi`、`in_irq`、`in_softirq（Bottom-half disable）`、`in_serving_softirq`，凡是處於這幾種狀態下，軟中斷都不會被執行；2）`local_softirq_pending`不為0，表明有軟中斷處理請求；
軟中斷執行的入口就是`invoke_softirq`，繼續分析一波：
- `invoke_softirq`函式中，根據中斷處理是否執行緒化進行分類處理，如果中斷已經進行了強制執行緒化處理（中斷強制執行緒化，需要在啟動的時候傳入引數`threadirqs`），那麼直接通過`wakeup_softirqd`喚醒核心執行緒來執行，否則的話則呼叫`__do_softirq`函式來處理；
- Linux核心會為每個CPU都建立一個核心執行緒`ksoftirqd`，通過`smpboot_register_percpu_thread`函式來完成，其中當核心執行緒執行時，在滿足條件的情況下會執行`run_ksoftirqd`函式，如果此時有軟中斷處理請求，呼叫`__do_softirq`來進行處理；
上圖中的邏輯可以看出，最終的核心處理都放置在`__do_softirq`函式中完成：
- `local_softirq_pending`函式用於讀取`__softirq_pending`欄位，可以類比於裝置驅動中的狀態暫存器，用於判斷是否有軟中斷處理請求；
- 軟中斷處理時會關閉`Bottom-half`，處理完後再開啟；
- `軟中斷處理時，會開啟本地中斷，處理完後關閉本地中斷`，這個地方對應到上文中提到的`Top-half`和`Bottom-half`機制，在`Bottom-half`處理的時候，是會將中斷開啟的，因此也就能繼續響應其他中斷，這個也就意味著其他中斷也能來打斷當前的`Bottom-half`處理；
- `while(softirq_bit = ffs(pending))`，迴圈讀取狀態位，直到處理完每一個軟中斷請求；
- 跳出`while`迴圈之後，再一次判斷是否又有新的軟中斷請求到來（由於它可能被中斷打斷，也就意味著可能有新的請求到來），有新的請求到來，則有三個條件判斷，滿足的話跳轉到`restart`處執行，否則呼叫`wakeup_sotfirqd`來喚醒核心執行緒來處理：
1. `time_before(jiffies, MAX_SOFTIRQ_TIME)`，軟中斷處理時間小於兩毫秒；
2. `!need_resched`，當前沒有程序排程的請求；
3. `max_restart = MAX_SOFTIRQ_RESTART`，跳轉到`restart`迴圈的次數不大於10次；
這三個條件的判斷，是基於延遲和公平的考慮，既要保證軟中斷儘快處理，又不能讓軟中斷處理一直佔據系統，正所謂`trade-off`的藝術；
`__do_softirq`既然可以在中斷處理過程中呼叫，也可以在`ksoftirqd`中呼叫，那麼`softirq`的執行可能有兩種context，插張圖吧：
讓我們來思考最後一個問題：硬體中斷觸發的時候是通過硬體裝置的電訊號，那麼軟中斷的觸發是通過什麼呢？答案是通過`raise_softirq`介面：
- 可以在中斷處理過程中呼叫`raise_softirq`來進行軟中斷處理請求，處理的實際也就是上文中提到過的`irq_exit`退出硬體中斷上下文之後再處理；
- `raise_softirq_irqoff`函式中，最終會呼叫到`or_softirq_pending`，該函式會去讀取本地CPU的`irq_stat`中`__softirq_pending`欄位，然後將對應的軟中斷號給置位，表明有該軟中斷的處理請求；
- `raise_softirq_irqoff`函式中，會判斷當前的請求的上下文環境，如果不在中斷上下文中，就可以通過喚醒核心執行緒來處理，如果在中斷上下文中處理，那就不執行；
- 多說一句，在軟中斷整個處理流程中，會經常看到`in_interrupt()`的條件判斷，這個可以確保軟中斷在CPU上的序列執行，避免巢狀；
### 2.2.3 軟中斷執行之二：Bottom-half Enable後
第二種軟中斷執行的時間點，在`Bottom-half`使能的時候，通常用於併發處理，程序空間上下文中進行呼叫：
- 在討論併發專題的時候，我們談到過`Bottom-half`與程序之間能產生資源爭奪的情況，如果在軟中斷和程序之間有臨界資源（軟中斷上下文優先順序高於程序上下文），那麼可以在程序上下文中呼叫`local_bh_disable/local_bh_enable`來對臨界資源保護；
- 圖中左側的函式，都是用於開啟`Bottom-half`的介面，可以看出是`spin_lock_bh/read_lock_bh/write_lock_bh`等併發處理介面的變種形式呼叫；
- `__local_bh_enable_ip`函式中，首先判斷呼叫該本介面時中斷是否是關閉的，如果已經關閉了再操作BH介面就會告警；
- `preempt_count_sub`需要與`preempt_count_add`配套使用，用於操作`thread_info->