1開場白

環(huán)境：

處理器架構(gòu)：arm64

內(nèi)核源碼：linux-5.10.50

ubuntu版本：20.04.1

代碼閱讀工具：vim+ctags+cscope

無論是任務(wù)處于用戶態(tài)還是內(nèi)核態(tài)，經(jīng)常會因為等待某些事件而睡眠（可能是等待IO讀寫完成，也可能等待其他內(nèi)核路徑釋放一把鎖等）。本文來探討一下，任務(wù)處于睡眠中有哪些狀態(tài)？睡眠對于任務(wù)來說究竟意味著什么？內(nèi)核是如何管理睡眠的任務(wù)的？我們會結(jié)合內(nèi)核源代碼來分析任務(wù)的睡眠，力求全方位角度來剖析。

注：由于篇幅問題，文章分為上下兩篇，且這里不區(qū)分進程和任務(wù)，統(tǒng)一使用任務(wù)來表示進程。

主要講解以下內(nèi)容：

睡眠的三種狀態(tài)

睡眠的內(nèi)核原理

用戶態(tài)睡眠

內(nèi)核態(tài)睡眠

總結(jié)

2. 睡眠的三種狀態(tài)

任務(wù)睡眠有三種狀態(tài)：

淺度睡眠

中度睡眠

深度睡眠

2.1 淺度睡眠

進程描述符的state使用TASK_INTERRUPTIBLE表示這種狀態(tài)。

為可中斷的睡眠狀態(tài)，這里可中斷是可以被信號所打斷（喚醒）。

這里給出被信號打斷/喚醒的代碼路徑：

kernel/signal.c

SYSCALL_DEFINE2（kill， pid_t， pid， int， sig）

->kill_something_info

->__kill_pgrp_info

->group_send_sig_info

->do_send_sig_info

->send_signal

->__send_signal

->complete_signal

->signal_wake_up

-> signal_wake_up_state（t， resume ？ TASK_WAKEKILL ： 0）

->wake_up_state（t， state | TASK_INTERRUPTIBLE）

->try_to_wake_up

可以看到在信號傳遞的時候，會通過signal_wake_up喚醒從處于可中斷睡眠狀態(tài)的任務(wù)。

2.2 中度睡眠

進程描述符的state使用TASK_KILLABLE表示這種狀態(tài)。

可以被致命信號所打斷。

這里給出被致命信號打斷/喚醒的代碼路徑：

include/linux/sched.h

#define TASK_KILLABLE （TASK_WAKEKILL | TASK_UNINTERRUPTIBLE）

kernel/signal.c

SYSCALL_DEFINE2（kill， pid_t， pid， int， sig）

->kill_something_info

->__kill_pgrp_info

->group_send_sig_info

->do_send_sig_info

->send_signal

->__send_signal

->complete_signal

->

if （sig_fatal（p， sig） &&

| ?。╯ignal->flags & SIGNAL_GROUP_EXIT） &&

| ！sigismember（&t->real_blocked， sig） &&

| （sig == SIGKILL || ！p->ptrace）） { //致命信號

...

signal_wake_up（t， 1）;

-> signal_wake_up_state（t， resume ？ TASK_WAKEKILL ： 0） // resume == 1

-> wake_up_state（t， state | TASK_INTERRUPTIBLE）

->try_to_wake_up

...

}

2.3 深度睡眠

進程描述符的state使用TASK_UNINTERRUPTIBLE表示這種狀態(tài)。

為不可中斷的睡眠狀態(tài)，不能被任何信號所喚醒（特定條件沒有滿足發(fā)生信號喚醒可能導致數(shù)據(jù)不一致等問題，這種場景使用這種睡眠狀態(tài)，如等待IO讀寫完成）。

3. 睡眠的內(nèi)核原理

睡眠都是主動發(fā)生調(diào)度，即主動調(diào)用主調(diào)度器。

睡眠的主要步驟如下：

1）設(shè)置任務(wù)狀態(tài)為睡眠狀態(tài)

2）記錄睡眠的任務(wù)

3）發(fā)起主動調(diào)度

下面我們來詳細解讀下這幾個步驟：

3.1 設(shè)置任務(wù)狀態(tài)為睡眠狀態(tài)

這一步很有必要，一來標識進入了睡眠狀態(tài)，二來是主調(diào)度器會根據(jù)睡眠標志將任務(wù)從運行隊列刪除。

注：睡眠狀態(tài)描述見上一小節(jié)！

3.2 記錄睡眠的任務(wù)

這一步也非常有必要，內(nèi)核會將即將睡眠的任務(wù)記錄下來，要么加入到鏈表中管理，要么使用數(shù)據(jù)結(jié)構(gòu)記錄。

如延遲睡眠場景，內(nèi)核將即將睡眠的任務(wù)記錄在定時器相關(guān)的數(shù)據(jù)結(jié)構(gòu)中；可睡眠的信號量場景中，內(nèi)核將即將睡眠的任務(wù)加入到信號量的相關(guān)鏈表中。

記錄的目的在于：當喚醒條件滿足時，喚醒函數(shù)能夠找到想要喚醒的任務(wù)。

3.3 發(fā)起主動調(diào)度

這一步是真正進行睡眠的操作，主要是調(diào)用主調(diào)度器來發(fā)起主動調(diào)度讓出處理器。

下面我們來看下主調(diào)度器為任務(wù)睡眠所作的處理：

kernel/sched/core.c

__schedule

->

prev_state = prev->state; //獲得前一個任務(wù)狀態(tài)

if （！preempt && prev_state） { //如果是主動調(diào)度 且任務(wù)狀態(tài)不為0

if （signal_pending_state（prev_state， prev）） { //有掛起的信號

prev->state = TASK_RUNNING; //設(shè)置狀態(tài)為可運行

} else {

deactivate_task（rq， prev， DEQUEUE_SLEEP | DEQUEUE_NOCLOCK）; //cpu運行隊列中刪除任務(wù)

}

}

next = pick_next_task（rq， prev， &rf）; //選擇下一個任務(wù)

context_switch //進行上下文切換

來看下deactivate_task對于睡眠任務(wù)做的主要工作：

deactivate_task

->deactivate_task（rq， prev， DEQUEUE_SLEEP | DEQUEUE_NOCLOCK）

->p->on_rq = （flags & DEQUEUE_SLEEP） ？ 0 ： TASK_ON_RQ_MIGRATING; //設(shè)置任務(wù)的on_rq 為0 標識是睡眠

dequeue_task（rq， p， flags）;

->p->sched_class->dequeue_task（rq， p， flags）

->dequeue_task_fair

->dequeue_entity

...

if （se ！= cfs_rq->curr） //不是cpu當前 任務(wù)

__dequeue_entity（cfs_rq， se）; //cfs運行隊列刪除

->se->on_rq = 0; //標識調(diào)度實體不在運行隊列?。?！

->if （?。╢lags & DEQUEUE_SLEEP））

se->vruntime -= cfs_rq->min_vruntime; //調(diào)度實體的虛擬運行時間 減去 cfs運行隊列的最小虛擬運行時間

deactivate_task會設(shè)置任務(wù)的on_rq 為0來 標識是睡眠 ，然后 調(diào)用到調(diào)度類的dequeue_task方法，在cfs中設(shè)置se->on_rq = 0標識調(diào)度實體不在cfs隊列。

可以看到，發(fā)起主動調(diào)度的時候，在主調(diào)度器中會做判斷：如果是主動調(diào)度且任務(wù)狀態(tài)不為0 （即為不是可運行的TASK_RUNNING）時，如果沒有掛起的信號，就會將任務(wù)從cpu的運行隊列中“刪除”，然后選擇下一個任務(wù)，進行上下文切換。

將即將睡眠的任務(wù)從cpu的運行隊列中“刪除”意義重大：主調(diào)度器再次選擇下一個任務(wù)的時候不會在選擇睡眠的任務(wù)（因為主調(diào)度器總是在運行隊列中選擇任務(wù)運行，除非任務(wù)被喚醒，重新加入運行隊列）。

注意：1.這里的刪除指的是設(shè)置對應標志如p->on_rq=0，se->on_rq = 0，當選擇下一個任務(wù)的時候不會在加入運行隊列中。2.即將睡眠的任務(wù)是cpu上的當前任務(wù)（curr指向）。3.調(diào)用主調(diào)度器后，即將睡眠的任務(wù)不會再次加入cpu運行隊列，除非被喚醒。

再來看下選擇下一個任務(wù)的時候會做哪些事情和睡眠有關(guān)（暫不考慮組調(diào)度情況）：

pick_next_task

->class->pick_next_task

->pick_next_task_fair //kernel/sched/fair.c

->if （prev）

put_prev_task（rq， prev）; //對前一個任務(wù)處理

se = pick_next_entity（cfs_rq， NULL）; //選擇下一個任務(wù)

set_next_entity（cfs_rq， se）;

主要看下put_prev_task：

put_prev_task

->prev->sched_class->put_prev_task（rq， prev）

->put_prev_task_fair

->put_prev_entity

-> if （prev->on_rq） { //前一個任務(wù)的調(diào)度實體on_rq不為0？

update_stats_wait_start（cfs_rq， prev）;

/* Put ‘current’ back into the tree. */

__enqueue_entity（cfs_rq， prev）; //重新加入cfs運行隊列

/* in ！on_rq case， update occurred at dequeue */

update_load_avg（cfs_rq， prev， 0）;

}

cfs_rq->curr = NULL; //設(shè)置cfs運行隊列的curr為NULL

put_prev_task所做的主要工作就是將前一個任務(wù)從cfs運行隊列中刪除，在這里就是通過調(diào)用__enqueue_entity將對應的調(diào)度實體重新加入cfs隊列的紅黑樹，但是對于即將睡眠的任務(wù)之前在主調(diào)度器中通過deactivate_task將prev->on_rq設(shè)置為0了，所以對于即將睡眠的任務(wù)來說，它對應的調(diào)度實體不會在重新加入cfs運行隊列的紅黑樹。

責任編輯：haq