Linux中內核搶占相關的基礎知識

今天要分享的是搶占相關的基礎知識。本文以內核搶占為引子，概述一下 Linux 搶占的圖景。我盡量避開細節(jié)問題和源碼分析。

什么是內核搶占？

別急，咱們慢慢來。

先理解搶占 （preemption） 這個概念：

involuntarily suspending a running process is called preemption

奪取一個進程的 cpu 使用權的行為就叫做搶占。

根據是否可以支持搶占，多任務操作系統(tǒng) （multitasking operating system） 分為 2 類：

1、cooperative multitasking os

這種 os，進程會一直運行直到它自愿停下來。這種自愿停止運行自己的行為稱為 yielding。協(xié)作式多任務系統(tǒng)，一聽就知道這是一個烏托邦式的系統(tǒng)，只有當所有進程都很 nice 并樂意經常 yielding 時，系統(tǒng)才能正常工作。如果某個進程太傻或者太壞，系統(tǒng)很快就完蛋了。

2、preemptive multitasking os

這種 os，會有一個調度器 （scheduler，其實就是一段用于調度進程的程序），scheduler 決定進程何時停止運行以及新進程何時開始運行。當一個進程的 cpu 使用權被 scheduler 分配給另一個進程時，就稱前一個進程被搶占了。

你可以把 sheduler 想象成非常智能的交警，交警按照一定的交通規(guī)則、當前的交通狀況以及車輛的優(yōu)先級 （救護車之類的），決定了哪些車可以行駛、哪些車要停下來等待。

很明顯，現(xiàn)階段，preemptive os 優(yōu)于 cooperative os。所以 Linux 被設計成 preemptive。

搶占的核心操作包括 2 個步驟：

1、從用戶態(tài)陷入到內核態(tài) （trap kernel），3 個路徑：

a. 系統(tǒng)調用，本質是 soft interrupt，通常就是一條硬件指令 （x86 的 int 0x80）。

b. 硬件中斷，最典型的就是會周期性發(fā)生的 timer 中斷，或者其他各種外設中斷。

c. exception，例如 page fault、div 0。

2、陷入到內核態(tài)后，在合適的時機下，調用 sheduler 選出一個最重要的進程，如果被選中的不是當前正在運行的進程的話，就會執(zhí)行 context switch 切換到新的進程。

根據搶占時機點的不同，搶占分為 2 種類型：

1、user preemption

這里的 user 并不是指在 user-space 里進行搶占，而是指在返回 user-space 前進行搶占，具體的：

When returning to user-space from a system call

When returning to user-space from an interrupt handler

即從 system call 和 interrupt handler 返回到 user-space 前進行搶占，這時仍然是在 kernel-space 里，搶占是需要非常高的權限的事情，user-space 沒權利也不應該干這事。

2、kernel preemption

Linux 2.6 之前是不支持內核搶占的。這意味著當處于用戶空間的進程請求內核服務時，在該進程阻塞（進入睡眠）等待某事（通常是 I/O）或系統(tǒng)調用完成之前，不能調度其他進程。支持內核搶占意味著當一個進程在內核里運行時，另一個進程可以搶占第一個進程并被允許運行，即使第一個進程尚未完成其在內核里的工作。

支持內核搶占 vs 不支持內核搶占

在上圖中，進程 A 已經通過系統(tǒng)調用進入內核，也許是對設備或文件的 write（） 調用。內核代表進程 A 執(zhí)行時，具有更高優(yōu)先級的進程 B 被中斷喚醒。內核搶占進程 A 并將 CPU 分配給進程 B，即使進程 A 既沒有阻塞也沒有完成其在內核里的工作。

內核搶占的時機：

When an interrupt handler exits， before returning to kernel-space

When kernel code becomes preemptible again

If a task in the kernel explicitly calls schedule（）

If a task in the kernel blocks （which results in a call to schedule（） ）

為什么要引入內核搶占？

根本原因：

trade-offs between latency and throughput

在系統(tǒng)延遲和吞吐量之間進行權衡。

并不是說內核搶占就是絕對的好，使用什么搶占機制最優(yōu)是跟你的應用場景掛鉤的。如果不是為了滿足用戶，內核其實是完全不想進行進程切換的，因為每一次 context switch，都會有 overhead，這些 overhead 就是對 cpu 的浪費，意味著吞吐量的下降。

但是，如果你想要系統(tǒng)的響應性好一點，就得盡量多的允許搶占的發(fā)生，這是 Linux 作為一個通用操作系統(tǒng)所必須支持的。當你的系統(tǒng)做到隨時都可以發(fā)生搶占時，系統(tǒng)的響應性就會非常好。

為了讓用戶根據自己的需求進行配置，Linux 提供了 3 種 Preemption Model。

CONFIG_PREEMPT_NONE=y：不允許內核搶占，吞吐量最大的 Model，一般用于 Server 系統(tǒng)。

CONFIG_PREEMPT_VOLUNTARY=y：在一些耗時較長的內核代碼中主動調用cond_resched（）讓出CPU，對吞吐量有輕微影響，但是系統(tǒng)響應會稍微快一些。

CONFIG_PREEMPT=y：除了處于持有 spinlock 時的 critical section，其他時候都允許內核搶占，響應速度進一步提升，吞吐量進一步下降，一般用于 Desktop / Embedded 系統(tǒng)。

另外，還有一個沒有合并進主線內核的 Model： CONFIG_PREEMPT_RT，這個模式幾乎將所有的 spinlock 都換成了 preemptable mutex，只剩下一些極其核心的地方仍然用禁止搶占的 spinlock，所以基本可以認為是隨時可被搶占。

搶占前的檢查

這里的檢查是同時針對所有的 preemption 的。如果你理解了前面的 4 種 preempiton model 的話，應該能感覺到其實是不用太嚴格區(qū)分 user / kernel preemption，所有搶占的作用和性質都一樣：降低 lantency，完全可以將它們一視同仁。

搶占的發(fā)生要同時滿足兩個條件：

需要搶占;

能搶占;

1、是否需要搶占？

判斷是否需要搶占的依據是：thread_info 的成員 flags 是否設置了 TIF_NEED_RESCHED 標志位。

相關的 API：

set_tsk_need_resched（） 用于設置該 flag。

tif_need_resched（） 被用來判斷該 flag 是否置位。

resched_curr（struct rq *rq），標記當前 runqueue 需要搶占。

2、是否能搶占？

搶占發(fā)生的前提是要確保此次搶占是安全的 （preempt-safe）。什么才是 preempt-safe：不產生 race condition / deadlock。

值得注意的是，只有 kernel preemption 才有被禁止的可能，而 user preemption 總是被允許，因此這時馬上就要返回 user space 了，肯定是處于一個可搶占的狀態(tài)了。

在引入內核搶占機制的同時引入了為 thread_info 添加了新的成員：preempt_count ，用來保證搶占的安全性，獲取鎖時會增加 preempt_count，釋放鎖時則會減少。搶占前會檢查 preempt_count 是否為 0，為 0 才允許搶占。

相關的 API：

preempt_enable（），使能內核搶占，可嵌套調用。

preempt_disable（），關閉內核搶占，可嵌套調用。

preempt_count（），返回 preempt_count。

什么場景會設置需要搶占 （TIF_NEED_RESCHED = 1）

通過 grep resched_curr 可以找出大多數(shù)標記搶占的場景。

下面列舉的是幾個我比較關心的場景。

1、周期性的時鐘中斷

時鐘中斷處理函數(shù)會調用 scheduler_tick（），它通過調度類（scheduling class） 的 task_tick 方法 檢查進程的時間片是否耗盡，如果耗盡則標記需要搶占：

// kernel/sched/core.c

void scheduler_tick（void）

{

［。..］

curr-》sched_class-》task_tick（rq， curr， 0）;

［。..］

}

Linux 的調度策略被封裝成調度類，例如 CFS、Real-Time。CFS 調度類的 task_tick（） 如下：

// kernel/sched/fair.c

task_tick_fair（）

-》 entity_tick（）

-》 resched_curr（rq_of（cfs_rq））;

2、喚醒進程的時候

當進程被喚醒的時候，如果優(yōu)先級高于 CPU 上的當前進程，就會觸發(fā)搶占。相應的內核代碼中，try_to_wake_up（） 最終通過 check_preempt_curr（） 檢查是否標記需要搶占：

// kernel/sched/core.c

void check_preempt_curr（struct rq *rq， struct task_struct *p， int flags）

{

const struct sched_class *class;

if （p-》sched_class == rq-》curr-》sched_class） {

rq-》curr-》sched_class-》check_preempt_curr（rq， p， flags）;

} else {

for_each_class（class） {

if （class == rq-》curr-》sched_class）

break;

if （class == p-》sched_class） {

resched_curr（rq）;

break;

}

}

}

［。..］

}

參數(shù) “p” 指向被喚醒進程，“rq” 代表搶占的 CPU。如果 p 的調度類和 rq 當前的調度類相同，則調用 rq 當前的調度類的 check_preempt_curr（） （例如 cfs 的 check_preempt_wakeup（）） 來判斷是否要標記需要搶占。

如果 p 的調度類 》 rq 當前的調度類，則用 resched_curr（） 標記需要搶占，反之，則不標記。

3、新進程創(chuàng)建的時候

如果新進程的優(yōu)先級高于 CPU 上的當前進程，會需要觸發(fā)搶占。相應的代碼是 sched_fork（），它再通過調度類的 task_fork（） 標記需要搶占：

// kernel/sched/core.c

int sched_fork（unsigned long clone_flags， struct task_struct *p）

{

［。..］

if （p-》sched_class-》task_fork）

p-》sched_class-》task_fork（p）;

［。..］

}

// kernel/sched/fair.c

static void task_fork_fair（struct task_struct *p）

{

［。..］

if （sysctl_sched_child_runs_first && curr && entity_before（curr， se）） {

resched_curr（rq）;

}

［。..］

}

4、進程修改 nice 值的時候

如果修改進程 nice 值導致優(yōu)先級高于 CPU 上的當前進程，也要標記需要搶占，代碼見 set_user_nice（）。

// kernel/sched/core.c

void set_user_nice（struct task_struct *p， long nice）

{

［。..］

// If the task increased its priority or is running and lowered its priority， then reschedule its CPU

if （delta 《 0 || （delta 》 0 && task_running（rq， p）））

resched_curr（rq）;

}

還有很多場景，這里就不一一列舉了。

什么場景下要禁止內核搶占 （preempt_count 》 0）

有幾種場景是明確需要關閉內核搶占的。

1、訪問 Per-CPU data structures 的時候

看下面這個例子：

struct this_needs_locking tux［NR_CPUS］;

tux［smp_processor_id（）］ = some_value;

/* task is preempted here.。. */

something = tux［smp_processor_id（）］;

如果搶占發(fā)生在注釋所在的那一行，當進程再次被調度時，smp_processor_id（） 值可能已經發(fā)生變化了，這種場景下需要通過禁止內核搶占來做到 preempt safe。

2、訪問 CPU state 的時候

這個很好理解，你正在操作 CPU 相關的寄存器以進行 context switch 時，肯定是不能再允許搶占。

asmlinkage __visible void __sched schedule（void）

{

struct task_struct *tsk = current;

sched_submit_work（tsk）;

do {

// 調度前禁止內核搶占

preempt_disable（）;

__schedule（false）;

sched_preempt_enable_no_resched（）;

} while （need_resched（））;

sched_update_worker（tsk）;

}

3、持有 spinlock 的時候

支持內核搶占，這意味著進程有可能與被搶占的進程在相同的 critical section 中運行。為防止這種情況，當持有自旋鎖時，要禁止內核搶占。

static inline void __raw_spin_lock（raw_spinlock_t *lock）

{

preempt_disable（）;

spin_acquire（&lock-》dep_map， 0， 0， _RET_IP_）;

LOCK_CONTENDED（lock， do_raw_spin_trylock， do_raw_spin_lock）;

}

還有很多場景，這里就不一一列舉了。

真正執(zhí)行搶占的地方

這部分是 platform 相關的，下面以 ARM64 Linux-5.4 為例，快速看下執(zhí)行搶占的具體代碼。

執(zhí)行 user preemption

系統(tǒng)調用和中斷返回用戶空間的時候：

它們都是在 ret_to_user（） 里判斷是否執(zhí)行用戶搶占。

// arch/arm64/kernel/entry.S

ret_to_user（） // 返回到用戶空間

work_pending（）

do_notify_resume（）

schedule（）

// arch/arm64/kernel/signal.c

asmlinkage void do_notify_resume（struct pt_regs *regs，

unsigned long thread_flags）

{

do {

［。..］

// 檢查是否要需要調度

if （thread_flags & _TIF_NEED_RESCHED） {

local_daif_restore（DAIF_PROCCTX_NOIRQ）;

schedule（）;

} else {

［。..］

} while （thread_flags & _TIF_WORK_MASK）;

}

執(zhí)行 kernel preemption

中斷返回內核空間的時候：

// arch/arm64/kernel/entry.S

el1_irq

irq_handler

arm64_preempt_schedule_irq

preempt_schedule_irq

__schedule（true）

// kernel/sched/core.c

/* This is the entry point to schedule（） from kernel preemption */

asmlinkage __visible void __sched preempt_schedule_irq（void）

{

［。..］

do {

preempt_disable（）;

local_irq_enable（）;

__schedule（true）;

local_irq_disable（）;

sched_preempt_enable_no_resched（）;

} while （need_resched（））;

exception_exit（prev_state）;

}

內核恢復為可搶占的時候：

前面列舉了集中關閉搶占的場景，當離開這些場景時，會恢復內核搶占。

例如 spinlock unlock 時：

static inline void __raw_spin_unlock（raw_spinlock_t *lock）

{

spin_release（&lock-》dep_map， 1， _RET_IP_）;

do_raw_spin_unlock（lock）;

preempt_enable（）; // 使能搶占時，如果需要，就會執(zhí)行搶占

}

// include/linux/preempt.h

#define preempt_enable（）

do {

barrier（）;

if （unlikely（preempt_count_dec_and_test（）））

__preempt_schedule（）;

} while （0）

內核顯式地要求調度的時候：

內核里有大量的地方會顯式地要求進行調度，最常見的是：cond_resched（） 和 sleep（）類函數(shù)，它們最終都會調用到 __schedule（）。

內核阻塞的時候：

例如 mutex，sem，waitqueue 獲取不到資源，或者是等待 IO。這種情況下進程會將自己的狀態(tài)從TASK_RUNNING 修改為 TASK_INTERRUPTIBLE，然后調用 schedule（） 主動讓出 CPU 并等待喚醒。

// block/blk-core.c

static struct request *get_request（struct request_queue *q， int op，

int op_flags， struct bio *bio，

gfp_t gfp_mask）

{

［。..］

prepare_to_wait_exclusive（&rl-》wait［is_sync］， &wait，

TASK_UNINTERRUPTIBLE）;

io_schedule（）; // 會調用 schedule（）;

［。..］

}

責任編輯：haq