【原創】Linux中斷子系統（三）-softirq和tasklet

LoyenWang發表於2020-06-14
Linux

背景

  • 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提供了靜態分配，關鍵的結構體描述如下，可以類比硬體中斷來理解：

/* 支援的軟中斷型別，可以認為是軟中斷號， 其中從上到下優先順序遞減 */
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介面來註冊，由於它實在是太簡單了，我忍不住想把程式碼貼上來：

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

也就是將軟中斷描述符表中對應描述符的handler函式指標指向對應的函式即可，以便軟中斷到來時進行回撥。

那麼，問題來了，什麼時候進行軟中斷函式回撥呢？

2.2.2 軟中斷執行之一：中斷處理後

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

  • Linux中斷子系統（二）-通用框架處理文章中講述了整個中斷處理流程，在接收到中斷訊號後，處理器進行異常模式切換，並跳轉到異常向量表處進行執行，關鍵的流程為：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->preempt_count欄位，加與減的值是一致的，而在__local_bh_enable_ip介面中，將cnt值的減操作分成了兩步：preempt_count_sub(cnt-1)和preempt_count_dec，這麼做的原因是執行完preempt_count_sub(cnt-1)後，thread_info->preempt_count欄位的值保留了1，把搶佔給關閉了，當do_softirq執行完畢後，再呼叫preempt_count_dec再減去剩下的1，進而開啟搶佔；
  • 為什麼在使能Bottom-half時要進行軟中斷處理呢？在併發處理時，可能已經把Bottom-half進行關閉了，如果此時中斷來了後，軟中斷不會被處理，在程式上下文中開啟Bottom-half時，這時候就會檢查是否有軟中斷處理請求了；

3. tasklet

從上文中分析可以看出，tasklet是軟中斷的一種型別，那麼兩者有啥區別呢？先說結論吧：

  • 軟中斷型別核心中都是靜態分配，不支援動態分配，而tasklet支援動態和靜態分配，也就是驅動程式中能比較方便的進行擴充套件；
  • 軟中斷可以在多個CPU上並行執行，因此需要考慮可重入問題，而tasklet會繫結在某個CPU上執行，執行完後再解綁，不要求重入問題，當然它的效能也就會下降一些；

3.1 資料結構

  • DEFINE_PER_CPU(struct tasklet_head, tasklet_vec)為每個CPU都分配了tasklet_head結構，該結構用來維護struct tasklet_struct連結串列，需要放到該CPU上執行的tasklet將會新增到該結構的連結串列中，核心中為每個CPU維護了兩個連結串列tasklet_vec和tasklet_vec_hi，對應兩個不同的優先順序，本文以tasklet_vec為例；
  • struct tasklet_struct為tasklet的抽象，幾個關鍵欄位如圖所示，通過next來連結成連結串列，通過state欄位來標識不同的狀態以確保能在CPU上序列執行，func函式指標在呼叫task_init()介面時進行初始化，並在最終觸發軟中斷時執行；

3.2 流程分析

  • tasklet本質上是一種軟中斷，所以它的呼叫流程與上文中討論的軟中斷流程是一致的；
  • 排程tasklet執行的介面是tasklet_schedule，如果tasklet沒有被排程則進行排程處理，將該tasklet新增到CPU對應的連結串列中，然後呼叫raise_softirq_irqoff來觸發軟中斷執行；
  • 軟中斷執行的處理函式是tasklet_action，這個在softirq_init函式中通過open_softirq函式進行註冊的；
  • tasklet_action函式，首先將該CPU上tasklet_vec中的連結串列挪到臨時連結串列list中，然後再對這個list進行遍歷處理，如果滿足執行條件則呼叫t->func()執行，並continue跳轉遍歷下一個節點。如果不滿足執行條件，則繼續將該tasklet新增回原來的tasklet_vec中，並再次觸發軟中斷；

3.3 介面

簡單貼一下介面吧：

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

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

/* 禁止tasklet被執行，本質上是增加tasklet_struct->count值，以便在排程時不滿足執行條件 */
void tasklet_disable(struct tasklet_struct *t);

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

/* 排程tasklet，通常在裝置驅動的中斷函式裡呼叫 */
void tasklet_schedule(struct tasklet_struct *t);

/* 殺死tasklet，確保不被排程和執行， 主要是設定state狀態位 */
void tasklet_kill(struct tasklet_struct *t)；

收工！

歡迎關注個人公眾號，不定期分享Linux核心機制文章。

相關文章