深入理解Linux內(nèi)核之內(nèi)核搶占
本文轉(zhuǎn)載自微信公眾號「Linux內(nèi)核遠航者」，作者Linux內(nèi)核遠航者。轉(zhuǎn)載本文請聯(lián)系Linux內(nèi)核遠航者公眾號。
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)系呢?搶占計數(shù)器究竟干什么用?... 本文我們就來好好討論下，關(guān)于內(nèi)核搶占的一些技術(shù)細節(jié)，力求讓大家理解內(nèi)核搶占。
注：本文主要關(guān)注CFS調(diào)度類。
2.內(nèi)核搶占和搶占式內(nèi)核
我們經(jīng)常使用uname -a命令能看到“PREEMPT”的字樣，沒錯，我們使用的是搶占式內(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)核呢? 實際上，支持內(nèi)核搶占的內(nèi)核叫做搶占式內(nèi)核，不支持內(nèi)核搶占的內(nèi)核叫做不可搶占式內(nèi)核。那么問題又來了，什么是內(nèi)核搶占呢?我們都知道，拿周期性的tick來說：對于用戶任務(wù)，當每個時鐘中斷到來后都會檢查它的實際運行時間是否超過理想運行時間，或者運行隊列中有沒有優(yōu)先級更高的進程，一般如果滿足其中一個條件就會設(shè)置重新調(diào)度標志，然后在中斷返回用戶態(tài)的前夕發(fā)生調(diào)度，這是所謂的用戶任務(wù)搶占。
但是如果處于一個內(nèi)核態(tài)的任務(wù)正在運行，這個時候發(fā)生中斷喚醒了一個高優(yōu)先級的任務(wù)，那么這個被喚醒的任務(wù)能否被調(diào)度執(zhí)行呢?這個時候就會分兩種情況分析，如果是搶占式內(nèi)核那么高優(yōu)先級任務(wù)就有可能搶占當前任務(wù)而調(diào)度執(zhí)行(之所有是有可能是因為兩者虛擬運行時間差值要大于搶占粒度才允許搶占)，如果是不可搶占式內(nèi)核那么不允許搶占，除非當前進程執(zhí)行完或者主動發(fā)生調(diào)度高優(yōu)先級進程該有機會被調(diào)度。
也就是說，支持內(nèi)核搶占的內(nèi)核不僅允許在用戶態(tài)的任務(wù)可以被搶占，處在內(nèi)核態(tài)的任務(wù)也允許被搶占(請注意這里說的是內(nèi)核態(tài)，因為用戶空間任務(wù)可以通過系統(tǒng)調(diào)用等進入內(nèi)核態(tài))，這樣對于交互性或者低延遲的應(yīng)用場景很友好，如手持設(shè)備和桌面應(yīng)用，響應(yīng)會很快。而對于服務(wù)器來說，它就對吞吐量要求較高，希望獲得更多的cpu時間，而交互性或者低延遲都是次要的，所以被設(shè)計成不可搶占式內(nèi)核。
下圖給出非搶占式內(nèi)核調(diào)度情況：
下圖給出搶占式內(nèi)核調(diào)度情況：
對比兩個圖可以發(fā)現(xiàn)：采用搶占式內(nèi)核調(diào)度的情況下，在中斷中喚醒一個高優(yōu)先級任務(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.
上面列舉了兩個編譯選項一個是支持內(nèi)核搶占一個是不支持內(nèi)核搶占，其實還有PREEMPT_VOLUNTARY和PREEMPT_RT，前者會顯式增加一些搶占點，后者用于支持實時性 。
3.重新調(diào)度標志和搶占計數(shù)器
內(nèi)核有些路徑是不允許調(diào)度的，如原子上下文，那么這個時候如果喚醒一個高優(yōu)先級的任務(wù)或者tick的時候檢查可重新調(diào)度條件滿足，那么高優(yōu)先級的任務(wù)將不能馬上得到執(zhí)行，但是我又要標識一下需要重新調(diào)度，那么就需要設(shè)置重新調(diào)度標志，當返回到可調(diào)度上下文的時候(如開搶占)，這個時候就會檢查是否設(shè)置了這個標志來決定是否調(diào)用調(diào)度器來選擇下一個任務(wù)來運行。
標識重新調(diào)度是設(shè)置：
- //當前任務(wù)的task_struct的thread_info的flag
- stsk->thread_info->flags設(shè)置TIF_NEED_RESCHED標志
- #define TIF_NEED_RESCHED 1 /* rescheduling necessary */
內(nèi)核的某些路徑上設(shè)置了這個標志之后，將在最近的調(diào)度點發(fā)生調(diào)度(可能是最近開啟搶占的時候，也可能是最近中斷異常返回的時候)。
當前任務(wù)被設(shè)置了重新調(diào)度標志，只是表明不久的將來會發(fā)生調(diào)度，并不是馬上發(fā)生調(diào)度，對于用戶任務(wù)來說就是中斷異常返回用戶態(tài)的前夕發(fā)生調(diào)度，而對于處于內(nèi)核態(tài)的任務(wù)來說，想要在內(nèi)核態(tài)搶占當前進程，僅僅置位重新調(diào)度標志還不行，還需要判斷當前進程的搶占計數(shù)器是否為0。
所有對于處于內(nèi)核態(tài)的任務(wù)來說，搶占計數(shù)器對于重新調(diào)度至關(guān)重要，只要搶占計數(shù)器不為0，無論被喚醒的任務(wù)在緊急都不能獲得調(diào)度器，我們來看看這個搶占計數(shù)器：
- tsk->thread_info->preempt.count
我們來看下對于arm64架構(gòu)，搶占計數(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)它是一個共用體，內(nèi)核某些路徑使用preempt_count，有的是preempt，為何會使用這么奇怪的定義呢?因為一個成員可以表示兩種狀態(tài)：重新調(diào)度標志和搶占計數(shù)器的數(shù)值
當需要重新調(diào)度的時候會置位flags的TIF_NEED_RESCHED標志，與此同時會將preempt.need_resched清零。當檢查thread_info 的preempt_count==0成立時，說明搶占計數(shù)器的數(shù)值為0且flags的TIF_NEED_RESCHED標志被置位，這個時候可以進程重新調(diào)度(如中斷返回內(nèi)核態(tài)前夕的檢查)。
下面看下如何設(shè)置重新調(dià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 }
當內(nèi)核的某個路徑設(shè)置重新調(diào)度標志(如時鐘中斷tick時)，會調(diào)用到resched_curr 來設(shè)置重新調(diào)度標志：可以看到除了設(shè)置任務(wù)的flags的TIF_NEED_RESCHED標志外，還設(shè)置了preempt.need_resched為0。
如何清除重新調(diào)度標志：
- kernel/sched/core.c
- __schedule //主動調(diào)度或搶占式調(diào)度 都會調(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標志外，會調(diào)用clear_preempt_need_resched來設(shè)置preempt.need_resched為1, 來清除重新調(diào)度。
下面為搶占計數(shù)器的各個域的表示：
0-7 表示搶占計數(shù) ，8-15表示軟中斷計數(shù)， 16-19表示硬中斷計數(shù)，20-23表示不可屏蔽中斷計數(shù)。當進入不同的上下文時會設(shè)置響應(yīng)的位域，表示在某個上下文中，當某個位域被設(shè)置，搶占計數(shù)器不為0，任務(wù)在內(nèi)核態(tài)就不容許被搶占。
所以，搶占計數(shù)器有兩個作用：一個是標識內(nèi)核路徑在某個原子上下文，一個是用來判斷是否允許任務(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())) //判斷是否在進程上下文
- 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()) //判斷是否在中斷上下文（包括硬中斷 軟中斷和不可屏蔽中斷）
- //判斷是否在原子上下文（搶占計數(shù)器不為0）
- 144 #define in_atomic() (preempt_count() != 0)
4.內(nèi)核搶占的調(diào)度時機
這里調(diào)度時機我將它細分為兩種情況，一種是不進行調(diào)度的cheek點，一種是真正的搶占點(即是調(diào)用主調(diào)度器進行調(diào)度)：
cheek點->
tick的時候 : 滿足條件(任務(wù)使用完理想運行時間，運行時間大于最小搶占粒度且運行隊列有優(yōu)先級更高的任務(wù)) 時，設(shè)置TIF_NEED_RESCHED標志,最近的搶占點發(fā)生調(diào)度 。
喚醒搶占 : 滿足條件(喚醒的任務(wù)與當前任務(wù)的虛擬運行時間差值大于最小喚醒搶占粒度 ，喚醒的任務(wù)虛擬運行時間更小) 時， 設(shè)置TIF_NEED_RESCHED標志，最近的搶占點發(fā)生調(diào)度。
搶占點->
中斷返回內(nèi)核態(tài) : 滿足條件(重新調(diào)度標志置位且搶占計數(shù)器為0) 時， 搶占式調(diào)度 。
打開搶占的時候 : (如開搶占，開中斷下半部，釋放自旋鎖) 滿足條件(重新調(diào)度標志置位且搶占計數(shù)器為0)時， 搶占式調(diào)度。
開啟軟中斷的時候 ： 滿足條件(重新調(diào)度標志置位且搶占計數(shù)器為0)時， 搶占式調(diào)度。
中斷返回內(nèi)核態(tài)是常規(guī)的搶占點，一般情況下即使沒有其他中斷產(chǎn)生，周期性的tick中斷也會發(fā)生， 滿足條件(重新調(diào)度標志置位且搶占計數(shù)器為0)時，當前任務(wù)就會被搶占。而在一些會發(fā)生多任務(wù)竟態(tài)的臨界區(qū)中，我們需要關(guān)閉內(nèi)核搶占，有的直接調(diào)用preempt_disable, 有的是間接調(diào)用preempt_disable(如申請自旋鎖的臨界區(qū)), 有的則是關(guān)閉軟中斷等，這些都會導致?lián)屨加嫈?shù)器不為0，但是在這些臨界區(qū)中如果中斷喚醒了高優(yōu)先級的任務(wù)，中斷返回內(nèi)核態(tài)的前夕是不能進行調(diào)度的，所以在這些臨界區(qū)結(jié)束的時候會檢查調(diào)度條件是否滿足，如果滿足進行搶占式調(diào)度，從而使得被喚醒的任務(wù)被及時的響應(yīng)。一般，一些cheek點設(shè)置了當前任務(wù)的重新調(diào)度標志之后，如果搶占計數(shù)器為0，會在最近的搶占點發(fā)生調(diào)度(就是上面所說的三種情況)。還有需要注意的是：關(guān)搶占的臨界區(qū)中，只是禁止了當前任務(wù)所在cpu的內(nèi)核搶占，其他cpu依然可以進行內(nèi)核搶占，如果這段臨界區(qū)有可能被其他cpu訪問到，可以直接使用自旋鎖來保護。
4.1 cheek點
1) 時鐘中斷tick時：
- 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.當前任務(wù)的實際運行時間大于理想運行時間
- 4375 resched_curr(rq_of(cfs_rq)); //設(shè)置重新調(diào)度標志
- 4389 if (delta_exec < sysctl_sched_min_granularity) //當前任務(wù)的實際運行時間 小于 最小調(diào)度粒度嗎？
- 4390 return;
- 4398 if (delta > ideal_runtime) //2.紅黑樹最左邊的任務(wù)的虛擬運行時間和當前任務(wù)的虛擬運行時間的差值小于 理想運行時間
- 4399 resched_curr(rq_of(cfs_rq)); //設(shè)置重新調(diào)度標志
每個時鐘tick到來時，會調(diào)用scheduler_tick來檢查是否需要重新調(diào)度，以下兩個條件有一個發(fā)生都會設(shè)置重新調(diào)度標志：
1.當前任務(wù)的實際運行時間大于理想運行時間(保證任務(wù)在一個調(diào)度周期內(nèi)運行時間不會超過理想運行時間，防止“流氓”任務(wù)一直霸占cpu，通過周期性的時鐘中斷奪回處理器的使用權(quán))。
2.當前任務(wù)的實際運行時間大于最小調(diào)度粒度，且紅黑樹最左邊的任務(wù)的虛擬運行時間和當前任務(wù)的虛擬運行時間的差值小于理想運行時間(紅黑樹中的高優(yōu)先級的任務(wù)可以搶占當前任務(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ù)的虛擬運行時間和當前任務(wù)的虛擬運行時間差值小于最新喚醒搶占粒度轉(zhuǎn)換的虛擬運行時間
- 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)度標志
正常喚醒路徑：
- 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ù)的時候，都有可能新喚醒的任務(wù)搶占當前任務(wù)，判斷條件如下：喚醒的任務(wù)的虛擬運行時間和當前任務(wù)的虛擬運行時間差值小于最小喚醒搶占粒度轉(zhuǎn)換的虛擬運行時間(喚醒的任務(wù)的虛擬運行時間更小)。
4.2 搶占點
上面介紹的都是cheek點，只是設(shè)置重新調(diào)度標志，并沒有讓搶占的任務(wù)運行，真正的搶占點是調(diào)用主調(diào)度器的時候。
1)中斷返回內(nèi)核態(tài)
當開啟內(nèi)核搶占的時候，在中斷返回內(nèi)核態(tài)的前夕，會檢查當前任務(wù)是否設(shè)置了重新調(diào)度標志且搶占計數(shù)器為0，如果都滿足，進行搶占式調(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
當發(fā)生中斷時，會執(zhí)行el1_irq來處理中斷，
672行 來讀取當前任務(wù)的thread_info.preempt_count 681行 判斷thread_info.preempt_count是否為0，如果為0 則調(diào)用682 行的arm64_preempt_schedule_irq 進行搶占式調(diào)度(上一節(jié)已經(jīng)分析過)。
下面看下?lián)屨际秸{(diào)度：
- arm64_preempt_schedule_irq
- ->preempt_schedule_irq
- ->__schedule(true) //調(diào)用主調(diào)度器進行搶占式調(diào)度
2)打開搶占的時候
開啟搶占：
- preempt_enable
- ->if (unlikely(preempt_count_dec_and_test())) \ //搶占計數(shù)器減一 為0
- __preempt_schedule(); \
- ->preempt_schedule //kernel/sched/core.c
- -> __schedule(true) //調(diào)用主調(diào)度器進行搶占式調(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)度器進行搶占式調(diào)度
其實，無論是主動進行調(diào)度還是搶占式調(diào)度都會調(diào)用__schedule，而__schedule是屬于關(guān)搶占上下文，在調(diào)度期間不允許被搶占。
5.不可搶占內(nèi)核的低延遲處理
下面我們來看下在沒有開啟內(nèi)核搶占的內(nèi)核中如何處理低延遲：
我們會看到在一些比較耗時的處理中如文件系統(tǒng)和內(nèi)存回收的一些路徑會調(diào)用cond_resched，它是干什么用呢：
下面是使用這個宏的例子：在內(nèi)存回收路徑中，會從不活躍的lru鏈表尾部取出一些頁面回收隔離到page_list中，最終會調(diào)用到shrink_page_list：
- mm/vmscan.c
- shrink_page_list
- ->
- 1084 while (!list_empty(page_list)) {
- ...
- 1091 cond_resched();
- ... //回收處理
- }
可以看到對于page_list中的每一個被隔離的候選回收頁，在處理之前都會調(diào)用到cond_resched來主動判斷是否需要重新調(diào)度。
下面我們來看下cond_resched這個宏實現(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為空，并沒有主動判斷重新調(diào)度的功能，只有非搶占式內(nèi)核才會調(diào)用_cond_resched來執(zhí)行主動檢查可搶占性。
下面我們來看下_cond_resched：
- 6671 #ifndef CONFIG_PREEMPTION
- 6672 int __sched _cond_resched(void)
- 6673 {
- 6674 if (should_resched(0)) { //判斷搶占計數(shù)器是否為0
- 6675 preempt_schedule_common(); //進行搶占式調(diào)度
- 6676 return 1;
- 6677 }
- 6678 rcu_all_qs();
- 6679 return 0;
- 6680 }
- 6681 EXPORT_SYMBOL(_cond_resched);
- 6682 #endif
會主動檢查搶占計數(shù)器是否為0(實際上搶占計數(shù)器是否為0且當前任務(wù)被設(shè)置了重新調(diào)度標志)，則進行搶占式調(diào)度。
實際上，對于非搶占式內(nèi)核來說，在內(nèi)核的很多地方，特別是文件系統(tǒng)操作和內(nèi)存管理相關(guān)的一些耗時路徑中，都已經(jīng)被內(nèi)核開發(fā)者識別出來，并使用cond_resched來減小延遲(感興趣的小伙伴可以通過grep和wc -l命令來查看一下)。
6.自愿內(nèi)核搶占
內(nèi)核搶占模型有一種叫做自愿內(nèi)核搶占模型(CONFIG_PREEMPT_VOLUNTARY=y)，可以使得內(nèi)核開發(fā)者在進行耗時操作的時候，主動檢查是否需要發(fā)生搶占式調(diào)度，這個和上一節(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時，might_resched才有效，否則為空。
可以驚奇的發(fā)現(xiàn)，當搜索might_resched在內(nèi)核中使用的使用的時候，并沒有看見有任何地方在使用，猜想是因為大多數(shù)耗時的內(nèi)核路徑，都已經(jīng)使用cond_resched來進行檢查是否具備調(diào)度時機。
7.總結(jié)
本文講解了內(nèi)核搶占的方方面面，非搶占式內(nèi)核主要用于服務(wù)器等對吞吐量要求較高的場景，而搶占式內(nèi)核主要用于嵌入式設(shè)備和桌面等對響應(yīng)要求較高的場景。內(nèi)核搶占的調(diào)度時機主要從check點和搶占點兩個角度去分析：check點是在合適的時機(如時鐘中斷tick時或者任務(wù)喚醒的時候)判斷是否需要重新調(diào)度任務(wù)，如果需要設(shè)置重新調(diào)度標志(need_resched)，并沒有馬上進行調(diào)度，然后在最近的搶占點發(fā)生調(diào)度;而搶占點是真正調(diào)用主調(diào)度器發(fā)生調(diào)度的時機，一般會在中斷返回內(nèi)核態(tài)或者重新開啟內(nèi)核搶占等情況下發(fā)生。最后，我們又分析了非搶占式內(nèi)核如何進行低延遲處理已經(jīng)自愿搶占式內(nèi)核如何實現(xiàn)自愿式搶占。
