Read the fucking source code!
--By 魯迅A picture is worth a thousand words.
--By 高爾基說明:
中斷子系統(tǒng)中有一個重要的設計機制,那就是Top-half和Bottom-half
,將緊急的工作放置在Top-half
中來處理,而將耗時的工作放置在Bottom-half
中來處理,這樣確保Top-half
能盡快完成處理,那么為什么需要這么設計呢?看一張圖就明白了:
Bottom-half
機制,包括了softirq
、tasklet
、workqueue
、以及前文中提到過的中斷線程化處理等,其中tasklet
又是基于softirq
來實現(xiàn)的,這也是本文討論的主題;在中斷處理過程中,離不開各種上下文的討論,了解不同上下文的區(qū)分有助于中斷處理的理解,所以,還是來一張老圖吧:
task_struct
結(jié)構(gòu)體中的thread_info.preempt_count
用于記錄當前任務所處的context
狀態(tài);PREEMPT_BITS
:用于記錄禁止搶占的次數(shù),禁止搶占一次該值就加1,使能搶占該值就減1;SOFTIRQ_BITS
:用于同步處理,關(guān)掉下半部的時候加1,打開下半部的時候減1;HARDIRQ_BITS
:用于表示處于硬件中斷上下文中;前戲結(jié)束了,直奔主題吧。
softirq
不支持動態(tài)分配,Linux kernel提供了靜態(tài)分配,關(guān)鍵的結(jié)構(gòu)體描述如下,可以類比硬件中斷來理解:
/* 支持的軟中斷類型,可以認為是軟中斷號, 其中從上到下優(yōu)先級遞減 */
enum
{
HI_SOFTIRQ=0, /* 最高優(yōu)先級軟中斷 */
TIMER_SOFTIRQ, /* Timer定時器軟中斷 */
NET_TX_SOFTIRQ, /* 發(fā)送網(wǎng)絡數(shù)據(jù)包軟中斷 */
NET_RX_SOFTIRQ, /* 接收網(wǎng)絡數(shù)據(jù)包軟中斷 */
BLOCK_SOFTIRQ, /* 塊設備軟中斷 */
IRQ_POLL_SOFTIRQ, /* 塊設備軟中斷 */
TASKLET_SOFTIRQ, /* tasklet軟中斷 */
SCHED_SOFTIRQ, /* 進程調(diào)度及負載均衡的軟中斷 */
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
};
/* 軟件中斷描述符,只包含一個handler函數(shù)指針 */
struct softirq_action {
void (*action)(struct softirq_action *);
};
/* 軟中斷描述符表,實際上就是一個全局的數(shù)組 */
static struct softirq_action softirq_vec[NR_SOFTIRQS] __cacheline_aligned_in_smp;
/* CPU軟中斷狀態(tài)描述,當某個軟中斷觸發(fā)時,__softirq_pending會置位對應的bit */
typedef struct {
unsigned int __softirq_pending;
unsigned int ipi_irqs[NR_IPI];
} ____cacheline_aligned irq_cpustat_t;
/* 每個CPU都會維護一個狀態(tài)信息結(jié)構(gòu) */
irq_cpustat_t irq_stat[NR_CPUS] ____cacheline_aligned;
/* 內(nèi)核為每個CPU都創(chuàng)建了一個軟中斷處理內(nèi)核線程 */
DEFINE_PER_CPU(struct task_struct *, ksoftirqd);
來一張圖吧:
softirq_vec[]
數(shù)組,類比硬件中斷描述符表irq_desc[]
,通過軟中斷號可以找到對應的handler
進行處理,比如圖中的tasklet_action
就是一個實際的handler
函數(shù);irq_cpustat_t
狀態(tài)結(jié)構(gòu),當某個軟中斷需要進行處理時,會將該結(jié)構(gòu)體中的__softirq_pending
字段或上1UL << XXX_SOFTIRQ
;中斷處理流程中設備驅(qū)動通過request_irq/request_threaded_irq
接口來注冊中斷處理函數(shù),而在軟中斷處理流程中,通過open_softirq
接口來注冊,由于它實在是太簡單了,我忍不住想把代碼貼上來:
void open_softirq(int nr, void (*action)(struct softirq_action *))
{
softirq_vec[nr].action = action;
}
也就是將軟中斷描述符表中對應描述符的handler
函數(shù)指針指向?qū)暮瘮?shù)即可,以便軟中斷到來時進行回調(diào)。
那么,問題來了,什么時候進行軟中斷函數(shù)回調(diào)呢?
先看第一種情況,用圖片來回答問題:
el0_irq->irq_handler->handle_arch_irq(gic->handle_irq)->handle_domain_irq->__handle_domain_irq
;__handle_domain_irq
函數(shù)中,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
,凡是處于這幾種狀態(tài)下,軟中斷都不會被執(zhí)行;2)local_softirq_pending
不為0,表明有軟中斷處理請求;軟中斷執(zhí)行的入口就是invoke_softirq
,繼續(xù)分析一波:
invoke_softirq
函數(shù)中,根據(jù)中斷處理是否線程化進行分類處理,如果中斷已經(jīng)進行了強制線程化處理(中斷強制線程化,需要在啟動的時候傳入?yún)?shù)threadirqs
),那么直接通過wakeup_softirqd
喚醒內(nèi)核線程來執(zhí)行,否則的話則調(diào)用__do_softirq
函數(shù)來處理;ksoftirqd
,通過smpboot_register_percpu_thread
函數(shù)來完成,其中當內(nèi)核線程運行時,在滿足條件的情況下會執(zhí)行run_ksoftirqd
函數(shù),如果此時有軟中斷處理請求,調(diào)用__do_softirq
來進行處理;上圖中的邏輯可以看出,最終的核心處理都放置在__do_softirq
函數(shù)中完成:
local_softirq_pending
函數(shù)用于讀取__softirq_pending
字段,可以類比于設備驅(qū)動中的狀態(tài)寄存器,用于判斷是否有軟中斷處理請求;Bottom-half
,處理完后再打開;軟中斷處理時,會打開本地中斷,處理完后關(guān)閉本地中斷
,這個地方對應到上文中提到的Top-half
和Bottom-half
機制,在Bottom-half
處理的時候,是會將中斷打開的,因此也就能繼續(xù)響應其他中斷,這個也就意味著其他中斷也能來打斷當前的Bottom-half
處理;while(softirq_bit = ffs(pending))
,循環(huán)讀取狀態(tài)位,直到處理完每一個軟中斷請求;while
循環(huán)之后,再一次判斷是否又有新的軟中斷請求到來(由于它可能被中斷打斷,也就意味著可能有新的請求到來),有新的請求到來,則有三個條件判斷,滿足的話跳轉(zhuǎn)到restart
處執(zhí)行,否則調(diào)用wakeup_sotfirqd
來喚醒內(nèi)核線程來處理:
time_before(jiffies, MAX_SOFTIRQ_TIME)
,軟中斷處理時間小于兩毫秒;!need_resched
,當前沒有進程調(diào)度的請求;max_restart = MAX_SOFTIRQ_RESTART
,跳轉(zhuǎn)到restart
循環(huán)的次數(shù)不大于10次;trade-off
的藝術(shù);__do_softirq
既然可以在中斷處理過程中調(diào)用,也可以在ksoftirqd
中調(diào)用,那么softirq
的執(zhí)行可能有兩種context,插張圖吧:
讓我們來思考最后一個問題:硬件中斷觸發(fā)的時候是通過硬件設備的電信號,那么軟中斷的觸發(fā)是通過什么呢?答案是通過raise_softirq
接口:
raise_softirq
來進行軟中斷處理請求,處理的實際也就是上文中提到過的irq_exit
退出硬件中斷上下文之后再處理;raise_softirq_irqoff
函數(shù)中,最終會調(diào)用到or_softirq_pending
,該函數(shù)會去讀取本地CPU的irq_stat
中__softirq_pending
字段,然后將對應的軟中斷號給置位,表明有該軟中斷的處理請求;raise_softirq_irqoff
函數(shù)中,會判斷當前的請求的上下文環(huán)境,如果不在中斷上下文中,就可以通過喚醒內(nèi)核線程來處理,如果在中斷上下文中處理,那就不執(zhí)行;第二種軟中斷執(zhí)行的時間點,在Bottom-half
使能的時候,通常用于并發(fā)處理,進程空間上下文中進行調(diào)用:
Bottom-half
與進程之間能產(chǎn)生資源爭奪的情況,如果在軟中斷和進程之間有臨界資源(軟中斷上下文優(yōu)先級高于進程上下文),那么可以在進程上下文中調(diào)用local_bh_disable/local_bh_enable
來對臨界資源保護;Bottom-half
的接口,可以看出是spin_lock_bh/read_lock_bh/write_lock_bh
等并發(fā)處理接口的變種形式調(diào)用;__local_bh_enable_ip
函數(shù)中,首先判斷調(diào)用該本接口時中斷是否是關(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)閉了,當do_softirq
執(zhí)行完畢后,再調(diào)用preempt_count_dec
再減去剩下的1,進而打開搶占;Bottom-half
時要進行軟中斷處理呢?在并發(fā)處理時,可能已經(jīng)把Bottom-half
進行關(guān)閉了,如果此時中斷來了后,軟中斷不會被處理,在進程上下文中打開Bottom-half
時,這時候就會檢查是否有軟中斷處理請求了;從上文中分析可以看出,tasklet
是軟中斷的一種類型,那么兩者有啥區(qū)別呢?先說結(jié)論吧:
tasklet
支持動態(tài)和靜態(tài)分配,也就是驅(qū)動程序中能比較方便的進行擴展;tasklet
會綁定在某個CPU上運行,運行完后再解綁,不要求重入問題,當然它的性能也就會下降一些;DEFINE_PER_CPU(struct tasklet_head, tasklet_vec)
為每個CPU都分配了tasklet_head
結(jié)構(gòu),該結(jié)構(gòu)用來維護struct tasklet_struct
鏈表,需要放到該CPU上運行的tasklet
將會添加到該結(jié)構(gòu)的鏈表中,內(nèi)核中為每個CPU維護了兩個鏈表tasklet_vec
和tasklet_vec_hi
,對應兩個不同的優(yōu)先級,本文以tasklet_vec
為例;struct tasklet_struct
為tasklet
的抽象,幾個關(guān)鍵字段如圖所示,通過next
來鏈接成鏈表,通過state
字段來標識不同的狀態(tài)以確保能在CPU上串行執(zhí)行,func
函數(shù)指針在調(diào)用task_init()
接口時進行初始化,并在最終觸發(fā)軟中斷時執(zhí)行;tasklet
本質(zhì)上是一種軟中斷,所以它的調(diào)用流程與上文中討論的軟中斷流程是一致的;tasklet
運行的接口是tasklet_schedule
,如果tasklet
沒有被調(diào)度則進行調(diào)度處理,將該tasklet
添加到CPU對應的鏈表中,然后調(diào)用raise_softirq_irqoff
來觸發(fā)軟中斷執(zhí)行;tasklet_action
,這個在softirq_init
函數(shù)中通過open_softirq
函數(shù)進行注冊的;tasklet_action
函數(shù),首先將該CPU上tasklet_vec
中的鏈表挪到臨時鏈表list
中,然后再對這個list
進行遍歷處理,如果滿足執(zhí)行條件則調(diào)用t->func()
執(zhí)行,并continue
跳轉(zhuǎn)遍歷下一個節(jié)點。如果不滿足執(zhí)行條件,則繼續(xù)將該tasklet
添加回原來的tasklet_vec
中,并再次觸發(fā)軟中斷;簡單貼一下接口吧:
/* 靜態(tài)分配tasklet */
DECLARE_TASKLET(name, func, data)
/* 動態(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)度時不滿足執(zhí)行條件 */
void tasklet_disable(struct tasklet_struct *t);
/* 使能tasklet,與tasklet_diable對應 */
void tasklet_enable(struct tasklet_struct *t);
/* 調(diào)度tasklet,通常在設備驅(qū)動的中斷函數(shù)里調(diào)用 */
void tasklet_schedule(struct tasklet_struct *t);
/* 殺死tasklet,確保不被調(diào)度和執(zhí)行, 主要是設置state狀態(tài)位 */
void tasklet_kill(struct tasklet_struct *t);
收工!