深入理解Linux內(nèi)核之內(nèi)核搶占
本文轉(zhuǎn)載自微信公眾號(hào)「Linux內(nèi)核遠(yuǎn)航者」，作者Linux內(nèi)核遠(yuǎn)航者。轉(zhuǎn)載本文請聯(lián)系Linux內(nèi)核遠(yuǎn)航者公眾號(hào)。
1.開場白
環(huán)境：
處理器架構(gòu)：arm64
內(nèi)核源碼：linux-5.11
ubuntu版本：20.04.1
代碼閱讀工具：vim+ctags+cscope
我們或許經(jīng)常聽說過內(nèi)核搶占，可是我們是否真正理解它呢?內(nèi)核搶占和搶占式內(nèi)核究竟有什么關(guān)系呢?搶占計(jì)數(shù)器究竟干什么用?... 本文我們就來好好討論下，關(guān)于內(nèi)核搶占的一些技術(shù)細(xì)節(jié)，力求讓大家理解內(nèi)核搶占。
注：本文主要關(guān)注CFS調(diào)度類。
2.內(nèi)核搶占和搶占式內(nèi)核
我們經(jīng)常使用uname -a命令能看到“PREEMPT”的字樣，沒錯(cuò)，我們使用的是搶占式內(nèi)核。
- # uname -a
- Linux (none) 5.11.0-g08a3831f3ae1 #1 SMP PREEMPT Fri Apr 30 17:41:53 CST 2021 aarch64 GNU/Linux
那什么是搶占式內(nèi)核呢? 實(shí)際上，支持內(nèi)核搶占的內(nèi)核叫做搶占式內(nèi)核，不支持內(nèi)核搶占的內(nèi)核叫做不可搶占式內(nèi)核。那么問題又來了，什么是內(nèi)核搶占呢?我們都知道，拿周期性的tick來說：對(duì)于用戶任務(wù)，當(dāng)每個(gè)時(shí)鐘中斷到來后都會(huì)檢查它的實(shí)際運(yùn)行時(shí)間是否超過理想運(yùn)行時(shí)間，或者運(yùn)行隊(duì)列中有沒有優(yōu)先級(jí)更高的進(jìn)程，一般如果滿足其中一個(gè)條件就會(huì)設(shè)置重新調(diào)度標(biāo)志，然后在中斷返回用戶態(tài)的前夕發(fā)生調(diào)度，這是所謂的用戶任務(wù)搶占。
但是如果處于一個(gè)內(nèi)核態(tài)的任務(wù)正在運(yùn)行，這個(gè)時(shí)候發(fā)生中斷喚醒了一個(gè)高優(yōu)先級(jí)的任務(wù)，那么這個(gè)被喚醒的任務(wù)能否被調(diào)度執(zhí)行呢?這個(gè)時(shí)候就會(huì)分兩種情況分析，如果是搶占式內(nèi)核那么高優(yōu)先級(jí)任務(wù)就有可能搶占當(dāng)前任務(wù)而調(diào)度執(zhí)行(之所有是有可能是因?yàn)閮烧咛摂M運(yùn)行時(shí)間差值要大于搶占粒度才允許搶占)，如果是不可搶占式內(nèi)核那么不允許搶占，除非當(dāng)前進(jìn)程執(zhí)行完或者主動(dòng)發(fā)生調(diào)度高優(yōu)先級(jí)進(jìn)程該有機(jī)會(huì)被調(diào)度。
也就是說，支持內(nèi)核搶占的內(nèi)核不僅允許在用戶態(tài)的任務(wù)可以被搶占，處在內(nèi)核態(tài)的任務(wù)也允許被搶占(請注意這里說的是內(nèi)核態(tài)，因?yàn)橛脩艨臻g任務(wù)可以通過系統(tǒng)調(diào)用等進(jìn)入內(nèi)核態(tài))，這樣對(duì)于交互性或者低延遲的應(yīng)用場景很友好，如手持設(shè)備和桌面應(yīng)用，響應(yīng)會(huì)很快。而對(duì)于服務(wù)器來說，它就對(duì)吞吐量要求較高，希望獲得更多的cpu時(shí)間，而交互性或者低延遲都是次要的，所以被設(shè)計(jì)成不可搶占式內(nèi)核。
下圖給出非搶占式內(nèi)核調(diào)度情況：
下圖給出搶占式內(nèi)核調(diào)度情況：
對(duì)比兩個(gè)圖可以發(fā)現(xiàn)：采用搶占式內(nèi)核調(diào)度的情況下，在中斷中喚醒一個(gè)高優(yōu)先級(jí)任務(wù)能夠得到很好的響應(yīng)。
關(guān)于搶占式內(nèi)核還是不可搶占式內(nèi)核的選擇在源碼的kernel/Kconfig.preempt有所描述：
- config PREEMPT_NONE
- bool "No Forced Preemption (Server)"
- help
- ¦ This is the traditional Linux preemption model, geared towards
- ¦ throughput. It will still provide good latencies most of the
- ¦ time, but there are no guarantees and occasional longer delays
- ¦ are possible.
- ¦ Select this option if you are building a kernel for a server or
- ¦ scientific/computation system, or if you want to maximize the
- ¦ raw processing power of the kernel, irrespective of scheduling
- ¦ latencies.
- config PREEMPT
- bool "Preemptible Kernel (Low-Latency Desktop)"
- depends on !ARCH_NO_PREEMPT
- select PREEMPTION
- select UNINLINE_SPIN_UNLOCK if !ARCH_INLINE_SPIN_UNLOCK
- select PREEMPT_DYNAMIC if HAVE_PREEMPT_DYNAMIC
- help
- ¦ This option reduces the latency of the kernel by making
- ¦ all kernel code (that is not executing in a critical section)
- ¦ preemptible. This allows reaction to interactive events by
- ¦ permitting a low priority process to be preempted involuntarily
- ¦ even if it is in kernel mode executing a system call and would
- ¦ otherwise not be about to reach a natural preemption point.
- ¦ This allows applications to run more 'smoothly' even when the
- ¦ system is under load, at the cost of slightly lower throughput
- ¦ and a slight runtime overhead to kernel code.
- ¦ Select this if you are building a kernel for a desktop or
- ¦ embedded system with latency requirements in the milliseconds
- ¦ range.
上面列舉了兩個(gè)編譯選項(xiàng)一個(gè)是支持內(nèi)核搶占一個(gè)是不支持內(nèi)核搶占，其實(shí)還有PREEMPT_VOLUNTARY和PREEMPT_RT，前者會(huì)顯式增加一些搶占點(diǎn)，后者用于支持實(shí)時(shí)性 。
3.重新調(diào)度標(biāo)志和搶占計(jì)數(shù)器
內(nèi)核有些路徑是不允許調(diào)度的，如原子上下文，那么這個(gè)時(shí)候如果喚醒一個(gè)高優(yōu)先級(jí)的任務(wù)或者tick的時(shí)候檢查可重新調(diào)度條件滿足，那么高優(yōu)先級(jí)的任務(wù)將不能馬上得到執(zhí)行，但是我又要標(biāo)識(shí)一下需要重新調(diào)度，那么就需要設(shè)置重新調(diào)度標(biāo)志，當(dāng)返回到可調(diào)度上下文的時(shí)候(如開搶占)，這個(gè)時(shí)候就會(huì)檢查是否設(shè)置了這個(gè)標(biāo)志來決定是否調(diào)用調(diào)度器來選擇下一個(gè)任務(wù)來運(yùn)行。
標(biāo)識(shí)重新調(diào)度是設(shè)置：
- //當(dāng)前任務(wù)的task_struct的thread_info的flag
- stsk->thread_info->flags設(shè)置TIF_NEED_RESCHED標(biāo)志
- #define TIF_NEED_RESCHED 1 /* rescheduling necessary */
內(nèi)核的某些路徑上設(shè)置了這個(gè)標(biāo)志之后，將在最近的調(diào)度點(diǎn)發(fā)生調(diào)度(可能是最近開啟搶占的時(shí)候，也可能是最近中斷異常返回的時(shí)候)。
當(dāng)前任務(wù)被設(shè)置了重新調(diào)度標(biāo)志，只是表明不久的將來會(huì)發(fā)生調(diào)度，并不是馬上發(fā)生調(diào)度，對(duì)于用戶任務(wù)來說就是中斷異常返回用戶態(tài)的前夕發(fā)生調(diào)度，而對(duì)于處于內(nèi)核態(tài)的任務(wù)來說，想要在內(nèi)核態(tài)搶占當(dāng)前進(jìn)程，僅僅置位重新調(diào)度標(biāo)志還不行，還需要判斷當(dāng)前進(jìn)程的搶占計(jì)數(shù)器是否為0。
所有對(duì)于處于內(nèi)核態(tài)的任務(wù)來說，搶占計(jì)數(shù)器對(duì)于重新調(diào)度至關(guān)重要，只要搶占計(jì)數(shù)器不為0，無論被喚醒的任務(wù)在緊急都不能獲得調(diào)度器，我們來看看這個(gè)搶占計(jì)數(shù)器：
- tsk->thread_info->preempt.count
我們來看下對(duì)于arm64架構(gòu)，搶占計(jì)數(shù)器的定義：
- 24 struct thread_info {
- 25 unsigned long flags; /* low level flags */
- 29 union {
- 30 u64 preempt_count; /* 0 => preemptible, <0 => bug */
- 31 struct {
- 32 #ifdef CONFIG_CPU_BIG_ENDIAN
- 33 u32 need_resched;
- 34 u32 count;
- 35 #else
- 36 u32 count;
- 37 u32 need_resched;
- 38 #endif
- 39 } preempt;
- 40 };
- 45 };
可以發(fā)現(xiàn)它是一個(gè)共用體，內(nèi)核某些路徑使用preempt_count，有的是preempt，為何會(huì)使用這么奇怪的定義呢?因?yàn)橐粋€(gè)成員可以表示兩種狀態(tài)：重新調(diào)度標(biāo)志和搶占計(jì)數(shù)器的數(shù)值
當(dāng)需要重新調(diào)度的時(shí)候會(huì)置位flags的TIF_NEED_RESCHED標(biāo)志，與此同時(shí)會(huì)將preempt.need_resched清零。當(dāng)檢查thread_info 的preempt_count==0成立時(shí)，說明搶占計(jì)數(shù)器的數(shù)值為0且flags的TIF_NEED_RESCHED標(biāo)志被置位，這個(gè)時(shí)候可以進(jìn)程重新調(diào)度(如中斷返回內(nèi)核態(tài)前夕的檢查)。
下面看下如何設(shè)置重新調(diào)度標(biāo)志：
- resched_curr //kernel/sched/core.c
- 613 if (cpu == smp_processor_id()) {
- 614 set_tsk_need_resched(curr);
- 615 set_preempt_need_resched();
- 616 return;
- 617 }
- 29 static inline void set_preempt_need_resched(void) //arch/arm64/include/asm/preempt.h
- 30 {
- 31 current_thread_info()->preempt.need_resched = 0;
- 32 }
當(dāng)內(nèi)核的某個(gè)路徑設(shè)置重新調(diào)度標(biāo)志(如時(shí)鐘中斷tick時(shí))，會(huì)調(diào)用到resched_curr 來設(shè)置重新調(diào)度標(biāo)志：可以看到除了設(shè)置任務(wù)的flags的TIF_NEED_RESCHED標(biāo)志外，還設(shè)置了preempt.need_resched為0。
如何清除重新調(diào)度標(biāo)志：
- kernel/sched/core.c
- __schedule //主動(dòng)調(diào)度或搶占式調(diào)度 都會(huì)調(diào)用到這
- 5046 clear_tsk_need_resched(prev);
- 5047 clear_preempt_need_resched();
- //arch/arm64/include/asm/preempt.h
- 34 static inline void clear_preempt_need_resched(void)
- 35 {
- 36 current_thread_info()->preempt.need_resched = 1;
- 37 }
可以看到在主調(diào)度器中，除了調(diào)用clear_tsk_need_resched來清除任務(wù)的flags的TIF_NEED_RESCHED標(biāo)志外，會(huì)調(diào)用clear_preempt_need_resched來設(shè)置preempt.need_resched為1, 來清除重新調(diào)度。
下面為搶占計(jì)數(shù)器的各個(gè)域的表示：
0-7 表示搶占計(jì)數(shù) ，8-15表示軟中斷計(jì)數(shù)， 16-19表示硬中斷計(jì)數(shù)，20-23表示不可屏蔽中斷計(jì)數(shù)。當(dāng)進(jìn)入不同的上下文時(shí)會(huì)設(shè)置響應(yīng)的位域，表示在某個(gè)上下文中，當(dāng)某個(gè)位域被設(shè)置，搶占計(jì)數(shù)器不為0，任務(wù)在內(nèi)核態(tài)就不容許被搶占。
所以，搶占計(jì)數(shù)器有兩個(gè)作用：一個(gè)是標(biāo)識(shí)內(nèi)核路徑在某個(gè)原子上下文，一個(gè)是用來判斷是否允許任務(wù)在內(nèi)核態(tài)被搶占。
- include/linux/preempt.h
- 85 /*
- 86 * Macros to retrieve the current execution context:
- 87 *
- 88 * in_nmi() - We're in NMI context
- 89 * in_hardirq() - We're in hard IRQ context
- 90 * in_serving_softirq() - We're in softirq context
- 91 * in_task() - We're in task context
- 92 */
- 93 #define in_nmi() (nmi_count()) //判斷是否在 不可屏蔽中斷上下文
- 94 #define in_hardirq() (hardirq_count()) //判斷是否在硬中斷上下文
- 95 #define in_serving_softirq() (softirq_count() & SOFTIRQ_OFFSET) //判斷是否在軟中斷上下文
- 96 #define in_task() (!(in_nmi() | in_hardirq() | in_serving_softirq())) //判斷是否在進(jìn)程上下文
- 97
- 98 /*
- 99 * The following macros are deprecated and should not be used in new code:
- 100 * in_irq() - Obsolete version of in_hardirq()
- 101 * in_softirq() - We have BH disabled, or are processing softirqs
- 102 * in_interrupt() - We're in NMI,IRQ,SoftIRQ context or have BH disabled
- 103 */
- 104 #define in_irq() (hardirq_count()) //判斷是否在硬中斷上下文
- 105 #define in_softirq() (softirq_count()) //判斷是否在軟中斷上下文（關(guān)閉軟中斷或者在執(zhí)行軟中斷）
- 106 #define in_interrupt() (irq_count()) //判斷是否在中斷上下文（包括硬中斷 軟中斷和不可屏蔽中斷）
- //判斷是否在原子上下文（搶占計(jì)數(shù)器不為0）
- 144 #define in_atomic() (preempt_count() != 0)
4.內(nèi)核搶占的調(diào)度時(shí)機(jī)
這里調(diào)度時(shí)機(jī)我將它細(xì)分為兩種情況，一種是不進(jìn)行調(diào)度的cheek點(diǎn)，一種是真正的搶占點(diǎn)(即是調(diào)用主調(diào)度器進(jìn)行調(diào)度)：
cheek點(diǎn)->
tick的時(shí)候 : 滿足條件(任務(wù)使用完理想運(yùn)行時(shí)間，運(yùn)行時(shí)間大于最小搶占粒度且運(yùn)行隊(duì)列有優(yōu)先級(jí)更高的任務(wù)) 時(shí)，設(shè)置TIF_NEED_RESCHED標(biāo)志,最近的搶占點(diǎn)發(fā)生調(diào)度 。
喚醒搶占 : 滿足條件(喚醒的任務(wù)與當(dāng)前任務(wù)的虛擬運(yùn)行時(shí)間差值大于最小喚醒搶占粒度 ，喚醒的任務(wù)虛擬運(yùn)行時(shí)間更小) 時(shí)， 設(shè)置TIF_NEED_RESCHED標(biāo)志，最近的搶占點(diǎn)發(fā)生調(diào)度。
搶占點(diǎn)->
中斷返回內(nèi)核態(tài) : 滿足條件(重新調(diào)度標(biāo)志置位且搶占計(jì)數(shù)器為0) 時(shí)， 搶占式調(diào)度 。
打開搶占的時(shí)候 : (如開搶占，開中斷下半部，釋放自旋鎖) 滿足條件(重新調(diào)度標(biāo)志置位且搶占計(jì)數(shù)器為0)時(shí)， 搶占式調(diào)度。
開啟軟中斷的時(shí)候 ： 滿足條件(重新調(diào)度標(biāo)志置位且搶占計(jì)數(shù)器為0)時(shí)， 搶占式調(diào)度。
中斷返回內(nèi)核態(tài)是常規(guī)的搶占點(diǎn)，一般情況下即使沒有其他中斷產(chǎn)生，周期性的tick中斷也會(huì)發(fā)生， 滿足條件(重新調(diào)度標(biāo)志置位且搶占計(jì)數(shù)器為0)時(shí)，當(dāng)前任務(wù)就會(huì)被搶占。而在一些會(huì)發(fā)生多任務(wù)竟態(tài)的臨界區(qū)中，我們需要關(guān)閉內(nèi)核搶占，有的直接調(diào)用preempt_disable, 有的是間接調(diào)用preempt_disable(如申請自旋鎖的臨界區(qū)), 有的則是關(guān)閉軟中斷等，這些都會(huì)導(dǎo)致?lián)屨加?jì)數(shù)器不為0，但是在這些臨界區(qū)中如果中斷喚醒了高優(yōu)先級(jí)的任務(wù)，中斷返回內(nèi)核態(tài)的前夕是不能進(jìn)行調(diào)度的，所以在這些臨界區(qū)結(jié)束的時(shí)候會(huì)檢查調(diào)度條件是否滿足，如果滿足進(jìn)行搶占式調(diào)度，從而使得被喚醒的任務(wù)被及時(shí)的響應(yīng)。一般，一些cheek點(diǎn)設(shè)置了當(dāng)前任務(wù)的重新調(diào)度標(biāo)志之后，如果搶占計(jì)數(shù)器為0，會(huì)在最近的搶占點(diǎn)發(fā)生調(diào)度(就是上面所說的三種情況)。還有需要注意的是：關(guān)搶占的臨界區(qū)中，只是禁止了當(dāng)前任務(wù)所在cpu的內(nèi)核搶占，其他cpu依然可以進(jìn)行內(nèi)核搶占，如果這段臨界區(qū)有可能被其他cpu訪問到，可以直接使用自旋鎖來保護(hù)。
4.1 cheek點(diǎn)
1) 時(shí)鐘中斷tick時(shí)：
- kernel/sched/core.c
- scheduler_tick
- ->curr->sched_class->task_tick(rq, curr, 0)
- ->task_tick_fair
- ->entity_tick
- ->check_preempt_tick
- ->4374 if (delta_exec > ideal_runtime) { //1.當(dāng)前任務(wù)的實(shí)際運(yùn)行時(shí)間大于理想運(yùn)行時(shí)間
- 4375 resched_curr(rq_of(cfs_rq)); //設(shè)置重新調(diào)度標(biāo)志
- 4389 if (delta_exec < sysctl_sched_min_granularity) //當(dāng)前任務(wù)的實(shí)際運(yùn)行時(shí)間 小于 最小調(diào)度粒度嗎？
- 4390 return;
- 4398 if (delta > ideal_runtime) //2.紅黑樹最左邊的任務(wù)的虛擬運(yùn)行時(shí)間和當(dāng)前任務(wù)的虛擬運(yùn)行時(shí)間的差值小于 理想運(yùn)行時(shí)間
- 4399 resched_curr(rq_of(cfs_rq)); //設(shè)置重新調(diào)度標(biāo)志
每個(gè)時(shí)鐘tick到來時(shí)，會(huì)調(diào)用scheduler_tick來檢查是否需要重新調(diào)度，以下兩個(gè)條件有一個(gè)發(fā)生都會(huì)設(shè)置重新調(diào)度標(biāo)志：
1.當(dāng)前任務(wù)的實(shí)際運(yùn)行時(shí)間大于理想運(yùn)行時(shí)間(保證任務(wù)在一個(gè)調(diào)度周期內(nèi)運(yùn)行時(shí)間不會(huì)超過理想運(yùn)行時(shí)間，防止“流氓”任務(wù)一直霸占cpu，通過周期性的時(shí)鐘中斷奪回處理器的使用權(quán))。
2.當(dāng)前任務(wù)的實(shí)際運(yùn)行時(shí)間大于最小調(diào)度粒度，且紅黑樹最左邊的任務(wù)的虛擬運(yùn)行時(shí)間和當(dāng)前任務(wù)的虛擬運(yùn)行時(shí)間的差值小于理想運(yùn)行時(shí)間(紅黑樹中的高優(yōu)先級(jí)的任務(wù)可以搶占當(dāng)前任務(wù))。
2)喚醒搶占：
在fork和正常的喚醒路徑上：
fork路徑:
- kernel/fork.c
- kernel_clone
- ->wake_up_new_task(p)
- ->check_preempt_curr(rq, p, WF_FORK)
- ->rq->curr->sched_class->check_preempt_curr(rq, p, flags)
- ->check_preempt_wakeup //kernel/sched/fair.c
- -> 6994 if (wakeup_preempt_entity(se, pse) == 1) { //喚醒的任務(wù)的虛擬運(yùn)行時(shí)間和當(dāng)前任務(wù)的虛擬運(yùn)行時(shí)間差值小于最新喚醒搶占粒度轉(zhuǎn)換的虛擬運(yùn)行時(shí)間
- 6995 /*
- 6996 ¦* Bias pick_next to pick the sched entity that is
- 6997 ¦* triggering this preemption.
- 6998 ¦*/
- 6999 if (!next_buddy_marked)
- 7000 set_next_buddy(pse);
- 7001 goto preempt;
- 7002 }
- 7003
- 7004 return;
- 7005
- 7006 preempt:
- 7007 resched_curr(rq); //設(shè)置重新調(diào)度標(biāo)志
正常喚醒路徑：
- kernel/sched/core.c
- wake_up_process
- ->try_to_wake_up
- ->ttwu_queue
- ->ttwu_do_activate
- ->ttwu_do_wakeup
- ->check_preempt_curr(rq, p, wake_flags)
無論是創(chuàng)建新任務(wù)或者是喚醒任務(wù)的時(shí)候，都有可能新喚醒的任務(wù)搶占當(dāng)前任務(wù)，判斷條件如下：喚醒的任務(wù)的虛擬運(yùn)行時(shí)間和當(dāng)前任務(wù)的虛擬運(yùn)行時(shí)間差值小于最小喚醒搶占粒度轉(zhuǎn)換的虛擬運(yùn)行時(shí)間(喚醒的任務(wù)的虛擬運(yùn)行時(shí)間更小)。
4.2 搶占點(diǎn)
上面介紹的都是cheek點(diǎn)，只是設(shè)置重新調(diào)度標(biāo)志，并沒有讓搶占的任務(wù)運(yùn)行，真正的搶占點(diǎn)是調(diào)用主調(diào)度器的時(shí)候。
1)中斷返回內(nèi)核態(tài)
當(dāng)開啟內(nèi)核搶占的時(shí)候，在中斷返回內(nèi)核態(tài)的前夕，會(huì)檢查當(dāng)前任務(wù)是否設(shè)置了重新調(diào)度標(biāo)志且搶占計(jì)數(shù)器為0，如果都滿足，進(jìn)行搶占式調(diào)度。
- arch/arm64/kernel/entry.S
- el1_irq
- -> 671 #ifdef CONFIG_PREEMPTION
- 672 ldr x24, [tsk, #TSK_TI_PREEMPT] // get preempt count
- 673 alternative_if ARM64_HAS_IRQ_PRIO_MASKING
- 674 /*
- 675 ¦* DA_F were cleared at start of handling. If anything is set in DAIF,
- 676 ¦* we come back from an NMI, so skip preemption
- 677 ¦*/
- 678 mrs x0, daif
- 679 orr x24, x24, x0
- 680 alternative_else_nop_endif
- 681 cbnz x24, 1f // preempt count != 0 || NMI return path
- 682 bl arm64_preempt_schedule_irq // irq en/disable is done inside
- 683 1:
- 684 #endif
當(dāng)發(fā)生中斷時(shí)，會(huì)執(zhí)行el1_irq來處理中斷，
672行 來讀取當(dāng)前任務(wù)的thread_info.preempt_count 681行 判斷thread_info.preempt_count是否為0，如果為0 則調(diào)用682 行的arm64_preempt_schedule_irq 進(jìn)行搶占式調(diào)度(上一節(jié)已經(jīng)分析過)。
下面看下?lián)屨际秸{(diào)度：
- arm64_preempt_schedule_irq
- ->preempt_schedule_irq
- ->__schedule(true) //調(diào)用主調(diào)度器進(jìn)行搶占式調(diào)度
2)打開搶占的時(shí)候
開啟搶占：
- preempt_enable
- ->if (unlikely(preempt_count_dec_and_test())) \ //搶占計(jì)數(shù)器減一 為0
- __preempt_schedule(); \
- ->preempt_schedule //kernel/sched/core.c
- -> __schedule(true) //調(diào)用主調(diào)度器進(jìn)行搶占式調(diào)度
釋放自旋鎖：
- spin_unlock
- ->raw_spin_unlock
- ->__raw_spin_unlock
- ->preempt_enable //如上
3) 開啟軟中斷
- local_bh_enable
- ->__local_bh_enable_ip
- ->preempt_check_resched
- ->if (should_resched(0)) \
- __preempt_schedule();
- ->preempt_schedule
- -> __schedule(true) //調(diào)用主調(diào)度器進(jìn)行搶占式調(diào)度
其實(shí)，無論是主動(dòng)進(jìn)行調(diào)度還是搶占式調(diào)度都會(huì)調(diào)用__schedule，而__schedule是屬于關(guān)搶占上下文，在調(diào)度期間不允許被搶占。
5.不可搶占內(nèi)核的低延遲處理
下面我們來看下在沒有開啟內(nèi)核搶占的內(nèi)核中如何處理低延遲：
我們會(huì)看到在一些比較耗時(shí)的處理中如文件系統(tǒng)和內(nèi)存回收的一些路徑會(huì)調(diào)用cond_resched，它是干什么用呢：
下面是使用這個(gè)宏的例子：在內(nèi)存回收路徑中，會(huì)從不活躍的lru鏈表尾部取出一些頁面回收隔離到page_list中，最終會(huì)調(diào)用到shrink_page_list：
- mm/vmscan.c
- shrink_page_list
- ->
- 1084 while (!list_empty(page_list)) {
- ...
- 1091 cond_resched();
- ... //回收處理
- }
可以看到對(duì)于page_list中的每一個(gè)被隔離的候選回收頁，在處理之前都會(huì)調(diào)用到cond_resched來主動(dòng)判斷是否需要重新調(diào)度。
下面我們來看下cond_resched這個(gè)宏實(shí)現(xiàn)：
- include/linux/sched.h
- 1868 /*
- 1869 * cond_resched() and cond_resched_lock(): latency reduction via
- 1870 * explicit rescheduling in places that are safe. The return
- 1871 * value indicates whether a reschedule was done in fact.
- 1872 * cond_resched_lock() will drop the spinlock before scheduling,
- 1873 */
- 1874 #ifndef CONFIG_PREEMPTION
- 1875 extern int _cond_resched(void);
- 1876 #else
- 1877 static inline int _cond_resched(void) { return 0; }
- 1878 #endif
- 1879
- 1880 #define cond_resched() ({ \
- 1881 ___might_sleep(__FILE__, __LINE__, 0); \
- 1882 _cond_resched(); \
- 1883 })
我們可以很清楚的看到，搶占式內(nèi)核中(CONFIG_PREEMPTION=y)cond_resched宏的_cond_resched為空，并沒有主動(dòng)判斷重新調(diào)度的功能，只有非搶占式內(nèi)核才會(huì)調(diào)用_cond_resched來執(zhí)行主動(dòng)檢查可搶占性。
下面我們來看下_cond_resched：
- 6671 #ifndef CONFIG_PREEMPTION
- 6672 int __sched _cond_resched(void)
- 6673 {
- 6674 if (should_resched(0)) { //判斷搶占計(jì)數(shù)器是否為0
- 6675 preempt_schedule_common(); //進(jìn)行搶占式調(diào)度
- 6676 return 1;
- 6677 }
- 6678 rcu_all_qs();
- 6679 return 0;
- 6680 }
- 6681 EXPORT_SYMBOL(_cond_resched);
- 6682 #endif
會(huì)主動(dòng)檢查搶占計(jì)數(shù)器是否為0(實(shí)際上搶占計(jì)數(shù)器是否為0且當(dāng)前任務(wù)被設(shè)置了重新調(diào)度標(biāo)志)，則進(jìn)行搶占式調(diào)度。
實(shí)際上，對(duì)于非搶占式內(nèi)核來說，在內(nèi)核的很多地方，特別是文件系統(tǒng)操作和內(nèi)存管理相關(guān)的一些耗時(shí)路徑中，都已經(jīng)被內(nèi)核開發(fā)者識(shí)別出來，并使用cond_resched來減小延遲(感興趣的小伙伴可以通過grep和wc -l命令來查看一下)。
6.自愿內(nèi)核搶占
內(nèi)核搶占模型有一種叫做自愿內(nèi)核搶占模型(CONFIG_PREEMPT_VOLUNTARY=y)，可以使得內(nèi)核開發(fā)者在進(jìn)行耗時(shí)操作的時(shí)候，主動(dòng)檢查是否需要發(fā)生搶占式調(diào)度，這個(gè)和上一節(jié)差不多。
- config PREEMPT_VOLUNTARY
- bool "Voluntary Kernel Preemption (Desktop)"
- depends on !ARCH_NO_PREEMPT
- help
- ¦ This option reduces the latency of the kernel by adding more
- ¦ "explicit preemption points" to the kernel code. These new
- ¦ preemption points have been selected to reduce the maximum
- ¦ latency of rescheduling, providing faster application reactions,
- ¦ at the cost of slightly lower throughput.
- ¦ This allows reaction to interactive events by allowing a
- ¦ low priority process to voluntarily preempt itself even if it
- ¦ is in kernel mode executing a system call. This allows
- ¦ applications to run more 'smoothly' even when the system is
- ¦ under load.
- ¦ Select this if you are building a kernel for a desktop system.
使用might_resched：
- 83 #ifdef CONFIG_PREEMPT_VOLUNTARY
- 84 extern int _cond_resched(void);
- 85 # define might_resched() _cond_resched()
- 86 #else
- 87 # define might_resched() do { } while (0)
- 88 #endif
發(fā)現(xiàn)只有CONFIG_PREEMPT_VOLUNTARY=y時(shí)，might_resched才有效，否則為空。
可以驚奇的發(fā)現(xiàn)，當(dāng)搜索might_resched在內(nèi)核中使用的使用的時(shí)候，并沒有看見有任何地方在使用，猜想是因?yàn)榇蠖鄶?shù)耗時(shí)的內(nèi)核路徑，都已經(jīng)使用cond_resched來進(jìn)行檢查是否具備調(diào)度時(shí)機(jī)。
7.總結(jié)
本文講解了內(nèi)核搶占的方方面面，非搶占式內(nèi)核主要用于服務(wù)器等對(duì)吞吐量要求較高的場景，而搶占式內(nèi)核主要用于嵌入式設(shè)備和桌面等對(duì)響應(yīng)要求較高的場景。內(nèi)核搶占的調(diào)度時(shí)機(jī)主要從check點(diǎn)和搶占點(diǎn)兩個(gè)角度去分析：check點(diǎn)是在合適的時(shí)機(jī)(如時(shí)鐘中斷tick時(shí)或者任務(wù)喚醒的時(shí)候)判斷是否需要重新調(diào)度任務(wù)，如果需要設(shè)置重新調(diào)度標(biāo)志(need_resched)，并沒有馬上進(jìn)行調(diào)度，然后在最近的搶占點(diǎn)發(fā)生調(diào)度;而搶占點(diǎn)是真正調(diào)用主調(diào)度器發(fā)生調(diào)度的時(shí)機(jī)，一般會(huì)在中斷返回內(nèi)核態(tài)或者重新開啟內(nèi)核搶占等情況下發(fā)生。最后，我們又分析了非搶占式內(nèi)核如何進(jìn)行低延遲處理已經(jīng)自愿搶占式內(nèi)核如何實(shí)現(xiàn)自愿式搶占。
