背景

• 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. 概述

中斷子系統(tǒng)中有一個(gè)重要的設(shè)計(jì)機(jī)制，那就是Top-half和Bottom-half，將緊急的工作放置在Top-half中來處理，而將耗時(shí)的工作放置在Bottom-half中來處理，這樣確保Top-half能盡快完成處理，那么為什么需要這么設(shè)計(jì)呢？看一張圖就明白了：

• ARM處理器在進(jìn)行中斷處理時(shí)，處理器進(jìn)行異常模式切換，此時(shí)會將中斷進(jìn)行關(guān)閉，處理完成后再將中斷打開；
• 如果中斷不分上下半部處理，那么意味著只有等上一個(gè)中斷完成處理后才會打開中斷，下一個(gè)中斷才能得到響應(yīng)。當(dāng)某個(gè)中斷處理處理時(shí)間較長時(shí)，很有可能就會造成其他中斷丟失而無法響應(yīng)，這個(gè)顯然是難以接受的，比如典型的時(shí)鐘中斷，作為系統(tǒng)的脈搏，它的響應(yīng)就需要得到保障；
• 中斷分成上下半部處理可以提高中斷的響應(yīng)能力，在上半部處理完成后便將中斷打開（通常上半部處理越快越好），這樣就可以響應(yīng)其他中斷了，等到中斷退出的時(shí)候再進(jìn)行下半部的處理；
• 中斷的Bottom-half機(jī)制，包括了softirq、tasklet、workqueue、以及前文中提到過的中斷線程化處理等，其中tasklet又是基于softirq來實(shí)現(xiàn)的，這也是本文討論的主題；

在中斷處理過程中，離不開各種上下文的討論，了解不同上下文的區(qū)分有助于中斷處理的理解，所以，還是來一張老圖吧：

• task_struct結(jié)構(gòu)體中的thread_info.preempt_count用于記錄當(dāng)前任務(wù)所處的context狀態(tài)；
• PREEMPT_BITS：用于記錄禁止搶占的次數(shù)，禁止搶占一次該值就加1，使能搶占該值就減1；
• SOFTIRQ_BITS：用于同步處理，關(guān)掉下半部的時(shí)候加1，打開下半部的時(shí)候減1；
• HARDIRQ_BITS：用于表示處于硬件中斷上下文中；

前戲結(jié)束了，直奔主題吧。

2. softirq

2.1 初始化

softirq不支持動(dòng)態(tài)分配，Linux kernel提供了靜態(tài)分配，關(guān)鍵的結(jié)構(gòu)體描述如下，可以類比硬件中斷來理解：

/* 支持的軟中斷類型，可以認(rèn)為是軟中斷號， 其中從上到下優(yōu)先級遞減 */
enum
{
	HI_SOFTIRQ=0,       /* 最高優(yōu)先級軟中斷 */
	TIMER_SOFTIRQ,      /* Timer定時(shí)器軟中斷 */
	NET_TX_SOFTIRQ,     /* 發(fā)送網(wǎng)絡(luò)數(shù)據(jù)包軟中斷 */
	NET_RX_SOFTIRQ,     /* 接收網(wǎng)絡(luò)數(shù)據(jù)包軟中斷 */
	BLOCK_SOFTIRQ,      /* 塊設(shè)備軟中斷 */
	IRQ_POLL_SOFTIRQ,   /* 塊設(shè)備軟中斷 */
	TASKLET_SOFTIRQ,    /* tasklet軟中斷 */
	SCHED_SOFTIRQ,      /* 進(jìn)程調(diào)度及負(fù)載均衡的軟中斷 */
	HRTIMER_SOFTIRQ, /* Unused, but kept as tools rely on thenumbering. Sigh! */
	RCU_SOFTIRQ,    /* Preferable RCU should always be the last softirq， RCU相關(guān)的軟中斷 */

	NR_SOFTIRQS
};

/* 軟件中斷描述符，只包含一個(gè)handler函數(shù)指針 */
struct softirq_action {
	void	(*action)(struct softirq_action *);
};
/* 軟中斷描述符表，實(shí)際上就是一個(gè)全局的數(shù)組 */
static struct softirq_action softirq_vec[NR_SOFTIRQS] __cacheline_aligned_in_smp;

/* CPU軟中斷狀態(tài)描述，當(dāng)某個(gè)軟中斷觸發(fā)時(shí)，__softirq_pending會置位對應(yīng)的bit */
typedef struct {
	unsigned int __softirq_pending;
	unsigned int ipi_irqs[NR_IPI];
} ____cacheline_aligned irq_cpustat_t;
/* 每個(gè)CPU都會維護(hù)一個(gè)狀態(tài)信息結(jié)構(gòu) */
irq_cpustat_t irq_stat[NR_CPUS] ____cacheline_aligned;

/* 內(nèi)核為每個(gè)CPU都創(chuàng)建了一個(gè)軟中斷處理內(nèi)核線程 */
DEFINE_PER_CPU(struct task_struct *, ksoftirqd);

來一張圖吧：

• softirq_vec[]數(shù)組，類比硬件中斷描述符表irq_desc[]，通過軟中斷號可以找到對應(yīng)的handler進(jìn)行處理，比如圖中的tasklet_action就是一個(gè)實(shí)際的handler函數(shù)；
• 軟中斷可以在不同的CPU上并行運(yùn)行，在同一個(gè)CPU上只能串行執(zhí)行；
• 每個(gè)CPU維護(hù)irq_cpustat_t狀態(tài)結(jié)構(gòu)，當(dāng)某個(gè)軟中斷需要進(jìn)行處理時(shí)，會將該結(jié)構(gòu)體中的__softirq_pending字段或上1UL << XXX_SOFTIRQ；

2.2 流程分析

2.2.1 軟中斷注冊

中斷處理流程中設(shè)備驅(qū)動(dòng)通過request_irq/request_threaded_irq接口來注冊中斷處理函數(shù)，而在軟中斷處理流程中，通過open_softirq接口來注冊，由于它實(shí)在是太簡單了，我忍不住想把代碼貼上來：

void open_softirq(int nr, void (*action)(struct softirq_action *))
{
	softirq_vec[nr].action = action;
}

也就是將軟中斷描述符表中對應(yīng)描述符的handler函數(shù)指針指向?qū)?yīng)的函數(shù)即可，以便軟中斷到來時(shí)進(jìn)行回調(diào)。

那么，問題來了，什么時(shí)候進(jìn)行軟中斷函數(shù)回調(diào)呢？

2.2.2 軟中斷執(zhí)行之一：中斷處理后

先看第一種情況，用圖片來回答問題：

• Linux中斷子系統(tǒng)（二）-通用框架處理文章中講述了整個(gè)中斷處理流程，在接收到中斷信號后，處理器進(jìn)行異常模式切換，并跳轉(zhuǎn)到異常向量表處進(jìn)行執(zhí)行，關(guān)鍵的流程為：el0_irq->irq_handler->handle_arch_irq(gic->handle_irq)->handle_domain_irq->__handle_domain_irq；
• 在__handle_domain_irq函數(shù)中，irq_enter和irq_exit分別用于來標(biāo)識進(jìn)入和離開硬件中斷上下文處理，這個(gè)從preempt_count_add/preempt_count_sub來操作HARDIRQ_OFFSET可以看出來，這也對應(yīng)到了上文中的Context描述圖；
• 在離開硬件中斷上下文后，如果!in_interrupt() && local_softirq_pending為真，則進(jìn)行軟中斷處理。這個(gè)條件有兩個(gè)含義：1）!in_interrupt()表明不能處在中斷上下文中，這個(gè)范圍包括in_nmi、in_irq、in_softirq（Bottom-half disable）、in_serving_softirq，凡是處于這幾種狀態(tài)下，軟中斷都不會被執(zhí)行；2）local_softirq_pending不為0，表明有軟中斷處理請求；

軟中斷執(zhí)行的入口就是invoke_softirq，繼續(xù)分析一波：

• invoke_softirq函數(shù)中，根據(jù)中斷處理是否線程化進(jìn)行分類處理，如果中斷已經(jīng)進(jìn)行了強(qiáng)制線程化處理（中斷強(qiáng)制線程化，需要在啟動(dòng)的時(shí)候傳入?yún)?shù)threadirqs），那么直接通過wakeup_softirqd喚醒內(nèi)核線程來執(zhí)行，否則的話則調(diào)用__do_softirq函數(shù)來處理；
• Linux內(nèi)核會為每個(gè)CPU都創(chuàng)建一個(gè)內(nèi)核線程ksoftirqd，通過smpboot_register_percpu_thread函數(shù)來完成，其中當(dāng)內(nèi)核線程運(yùn)行時(shí)，在滿足條件的情況下會執(zhí)行run_ksoftirqd函數(shù)，如果此時(shí)有軟中斷處理請求，調(diào)用__do_softirq來進(jìn)行處理；

上圖中的邏輯可以看出，最終的核心處理都放置在__do_softirq函數(shù)中完成：

• local_softirq_pending函數(shù)用于讀取__softirq_pending字段，可以類比于設(shè)備驅(qū)動(dòng)中的狀態(tài)寄存器，用于判斷是否有軟中斷處理請求；
• 軟中斷處理時(shí)會關(guān)閉Bottom-half，處理完后再打開；
• 軟中斷處理時(shí)，會打開本地中斷，處理完后關(guān)閉本地中斷，這個(gè)地方對應(yīng)到上文中提到的Top-half和Bottom-half機(jī)制，在Bottom-half處理的時(shí)候，是會將中斷打開的，因此也就能繼續(xù)響應(yīng)其他中斷，這個(gè)也就意味著其他中斷也能來打斷當(dāng)前的Bottom-half處理；
• while(softirq_bit = ffs(pending))，循環(huán)讀取狀態(tài)位，直到處理完每一個(gè)軟中斷請求；
• 跳出while循環(huán)之后，再一次判斷是否又有新的軟中斷請求到來（由于它可能被中斷打斷，也就意味著可能有新的請求到來），有新的請求到來，則有三個(gè)條件判斷，滿足的話跳轉(zhuǎn)到restart處執(zhí)行，否則調(diào)用wakeup_sotfirqd來喚醒內(nèi)核線程來處理：
  1. time_before(jiffies, MAX_SOFTIRQ_TIME)，軟中斷處理時(shí)間小于兩毫秒；
  2. !need_resched，當(dāng)前沒有進(jìn)程調(diào)度的請求；
  3. max_restart = MAX_SOFTIRQ_RESTART，跳轉(zhuǎn)到restart循環(huán)的次數(shù)不大于10次；
     這三個(gè)條件的判斷，是基于延遲和公平的考慮，既要保證軟中斷盡快處理，又不能讓軟中斷處理一直占據(jù)系統(tǒng)，正所謂trade-off的藝術(shù)；

__do_softirq既然可以在中斷處理過程中調(diào)用，也可以在ksoftirqd中調(diào)用，那么softirq的執(zhí)行可能有兩種context，插張圖吧：

讓我們來思考最后一個(gè)問題：硬件中斷觸發(fā)的時(shí)候是通過硬件設(shè)備的電信號，那么軟中斷的觸發(fā)是通過什么呢？答案是通過raise_softirq接口：

• 可以在中斷處理過程中調(diào)用raise_softirq來進(jìn)行軟中斷處理請求，處理的實(shí)際也就是上文中提到過的irq_exit退出硬件中斷上下文之后再處理；
• raise_softirq_irqoff函數(shù)中，最終會調(diào)用到or_softirq_pending，該函數(shù)會去讀取本地CPU的irq_stat中__softirq_pending字段，然后將對應(yīng)的軟中斷號給置位，表明有該軟中斷的處理請求；
• raise_softirq_irqoff函數(shù)中，會判斷當(dāng)前的請求的上下文環(huán)境，如果不在中斷上下文中，就可以通過喚醒內(nèi)核線程來處理，如果在中斷上下文中處理，那就不執(zhí)行；
• 多說一句，在軟中斷整個(gè)處理流程中，會經(jīng)常看到in_interrupt()的條件判斷，這個(gè)可以確保軟中斷在CPU上的串行執(zhí)行，避免嵌套；

2.2.3 軟中斷執(zhí)行之二：Bottom-half Enable后

第二種軟中斷執(zhí)行的時(shí)間點(diǎn)，在Bottom-half使能的時(shí)候，通常用于并發(fā)處理，進(jìn)程空間上下文中進(jìn)行調(diào)用：

• 在討論并發(fā)專題的時(shí)候，我們談到過Bottom-half與進(jìn)程之間能產(chǎn)生資源爭奪的情況，如果在軟中斷和進(jìn)程之間有臨界資源（軟中斷上下文優(yōu)先級高于進(jìn)程上下文），那么可以在進(jìn)程上下文中調(diào)用local_bh_disable/local_bh_enable來對臨界資源保護(hù)；
• 圖中左側(cè)的函數(shù)，都是用于打開Bottom-half的接口，可以看出是spin_lock_bh/read_lock_bh/write_lock_bh等并發(fā)處理接口的變種形式調(diào)用；
• __local_bh_enable_ip函數(shù)中，首先判斷調(diào)用該本接口時(shí)中斷是否是關(guān)閉的，如果已經(jīng)關(guān)閉了再操作BH接口就會告警；
• preempt_count_sub需要與preempt_count_add配套使用，用于操作thread_info->preempt_count字段，加與減的值是一致的，而在__local_bh_enable_ip接口中，將cnt值的減操作分成了兩步：preempt_count_sub(cnt-1)和preempt_count_dec，這么做的原因是執(zhí)行完preempt_count_sub(cnt-1)后，thread_info->preempt_count字段的值保留了1，把搶占給關(guān)閉了，當(dāng)do_softirq執(zhí)行完畢后，再調(diào)用preempt_count_dec再減去剩下的1，進(jìn)而打開搶占；
• 為什么在使能Bottom-half時(shí)要進(jìn)行軟中斷處理呢？在并發(fā)處理時(shí)，可能已經(jīng)把Bottom-half進(jìn)行關(guān)閉了，如果此時(shí)中斷來了后，軟中斷不會被處理，在進(jìn)程上下文中打開Bottom-half時(shí)，這時(shí)候就會檢查是否有軟中斷處理請求了；

3. tasklet

從上文中分析可以看出，tasklet是軟中斷的一種類型，那么兩者有啥區(qū)別呢？先說結(jié)論吧：

• 軟中斷類型內(nèi)核中都是靜態(tài)分配，不支持動(dòng)態(tài)分配，而tasklet支持動(dòng)態(tài)和靜態(tài)分配，也就是驅(qū)動(dòng)程序中能比較方便的進(jìn)行擴(kuò)展；
• 軟中斷可以在多個(gè)CPU上并行運(yùn)行，因此需要考慮可重入問題，而tasklet會綁定在某個(gè)CPU上運(yùn)行，運(yùn)行完后再解綁，不要求重入問題，當(dāng)然它的性能也就會下降一些；

3.1 數(shù)據(jù)結(jié)構(gòu)

• DEFINE_PER_CPU(struct tasklet_head, tasklet_vec)為每個(gè)CPU都分配了tasklet_head結(jié)構(gòu)，該結(jié)構(gòu)用來維護(hù)struct tasklet_struct鏈表，需要放到該CPU上運(yùn)行的tasklet將會添加到該結(jié)構(gòu)的鏈表中，內(nèi)核中為每個(gè)CPU維護(hù)了兩個(gè)鏈表tasklet_vec和tasklet_vec_hi，對應(yīng)兩個(gè)不同的優(yōu)先級，本文以tasklet_vec為例；
• struct tasklet_struct為tasklet的抽象，幾個(gè)關(guān)鍵字段如圖所示，通過next來鏈接成鏈表，通過state字段來標(biāo)識不同的狀態(tài)以確保能在CPU上串行執(zhí)行，func函數(shù)指針在調(diào)用task_init()接口時(shí)進(jìn)行初始化，并在最終觸發(fā)軟中斷時(shí)執(zhí)行；

3.2 流程分析

• tasklet本質(zhì)上是一種軟中斷，所以它的調(diào)用流程與上文中討論的軟中斷流程是一致的；
• 調(diào)度tasklet運(yùn)行的接口是tasklet_schedule，如果tasklet沒有被調(diào)度則進(jìn)行調(diào)度處理，將該tasklet添加到CPU對應(yīng)的鏈表中，然后調(diào)用raise_softirq_irqoff來觸發(fā)軟中斷執(zhí)行；
• 軟中斷執(zhí)行的處理函數(shù)是tasklet_action，這個(gè)在softirq_init函數(shù)中通過open_softirq函數(shù)進(jìn)行注冊的；
• tasklet_action函數(shù)，首先將該CPU上tasklet_vec中的鏈表挪到臨時(shí)鏈表list中，然后再對這個(gè)list進(jìn)行遍歷處理，如果滿足執(zhí)行條件則調(diào)用t->func()執(zhí)行，并continue跳轉(zhuǎn)遍歷下一個(gè)節(jié)點(diǎn)。如果不滿足執(zhí)行條件，則繼續(xù)將該tasklet添加回原來的tasklet_vec中，并再次觸發(fā)軟中斷；

3.3 接口

簡單貼一下接口吧：

/* 靜態(tài)分配tasklet */
DECLARE_TASKLET(name, func, data)

/* 動(dòng)態(tài)分配tasklet */
void tasklet_init(struct tasklet_struct *t, void (*func)(unsigned long), unsigned long data);

/* 禁止tasklet被執(zhí)行，本質(zhì)上是增加tasklet_struct->count值，以便在調(diào)度時(shí)不滿足執(zhí)行條件 */
void tasklet_disable(struct tasklet_struct *t);

/* 使能tasklet，與tasklet_diable對應(yīng) */
void tasklet_enable(struct tasklet_struct *t);

/* 調(diào)度tasklet，通常在設(shè)備驅(qū)動(dòng)的中斷函數(shù)里調(diào)用 */
void tasklet_schedule(struct tasklet_struct *t);

/* 殺死tasklet，確保不被調(diào)度和執(zhí)行， 主要是設(shè)置state狀態(tài)位 */
void tasklet_kill(struct tasklet_struct *t)；

收工！