Linux 進程管理之調度和進程切換
什麼是調度？按照某種調度算法，從進程的 ready 隊列中選擇進程給 CPU。
爲什麼要調度？爲了最大限度的利用 CPU。
調度相關結構體
task_struct
我們先把 task_struct 中和調度相關的結構拎出來：
struct task_struct {
......
/*
*調度類。用 sched_class 對調度器進行抽象
*Stop調度器:stop_sched_class
*Deadline調度器:dl_sched_class
*RT調度器:rt_sched_class
*CFS調度器:cfs_sched_class
*IDLE-Task調度器:idle_sched_class
*/
const struct sched_class *sched_class;
//CFS調度實體
struct sched_entity se;
//RT調度實體
struct sched_rt_entity rt;
......
#ifdef CONFIG_CGROUP_SCHED
//任務組（在每個CPU上都會維護一個CFS調度實體、CFS運行隊列; RT調度實體，RT運行隊列）
struct task_group *sched_task_group;
#endif
//DL調度實體
struct sched_dl_entity dl;
......
/*
*進程的調度策略,有6種。
*限期進程調度策略:SCHED_DEADLINE。DL調度器
*實時進程調度策略:SCHED_FIFO，SCHED_RR。RT調度器
*普通進程調度策略:SCHED_NORMAL，SCHED_BATCH，SCHED_IDLE。CFS調度器
*/
unsigned int policy;
......
}- struct sched_class 對調度器進行抽象，一共分爲 5 類：
-
Stop 調度器：優先級最高的調度類，可以搶佔其他所有進程，不能被其他進程搶佔；
-
Deadline 調度器：使用紅黑樹，把進程按照絕對截止期限進行排序，選擇最小進程進行調度運行；
-
RT 調度器：爲每個優先級維護一個隊列；
-
CFS 調度器：採用完全公平調度算法，引入虛擬運行時間概念；
-
IDLE-Task 調度器：每個 CPU 都會有一個 idle 線程，當沒有其他進程可以調度時，調度運行 idle 線程；
- unsigned int policy 進程的調度策略有 6 種，用戶可以調用調度器裏的不同調度策略：
-
SCHED_DEADLINE：使 task 選擇 Deadline 調度器來調度運行
-
SCHED_RR：時間片輪轉，進程用完時間片後加入優先級對應運行隊列的尾部，把 CPU 讓給同優先級的其他進程；
-
SCHED_FIFO：先進先出調度沒有時間片，沒有更高優先級的情況下，只能等待主動讓出 CPU；
-
SCHED_NORMAL：使 task 選擇 CFS 調度器來調度運行；
-
SCHED_BATCH：批量處理，使 task 選擇 CFS 調度器來調度運行；
-
SCHED_IDLE：使 task 以最低優先級選擇 CFS 調度器來調度運行；
-
struct sched_entity se；採用 CFS 算法調度的普通非實時進程的調度實體
-
struct sched_rt_entity rt；採用 Roound-Robin 或者 FIFO 算法調度的實時調度實體
-
struct sched_dl_entity dl; 採用 EDF 算法調度的實時調度實體
分配給 CPU 的 task，作爲調度實體加入到運行隊列中
runqueue 運行隊列
struct rq {
......
//三個調度隊列：CFS調度，RT調度，DL調度
struct cfs_rq cfs;
struct rt_rq rt;
struct dl_rq dl;
......
//idle指向空閒內核線程, stop指向遷移內核線程
struct task_struct *curr, *idle, *stop;
......
}三個調度隊列：
-
struct cfs_rq cfs; CFS 調度隊列
-
struct rt_rq rt; RT 調度隊列
-
struct dl_rq dl; DL 調度隊列
每個 CPU 都有一個運行隊列，每個運行隊列中有三個調度隊列，task 作爲調度實體加入到各自的調度隊列中。
調度流程
調度的本質就是選擇下一個進程來運行，調度的過程分爲兩步：
-
1. 設置調度標記
爲 CPU 上正在運行的進程 thread_info 結構體裏的 flags 成員設置 TIF_NEED_RESCHED。
那麼，什麼時候設置 TIF_NEED_RESCHED 呢 ？
-
scheduler_tick 時鐘中斷
-
wake_up_process 喚醒進程的時候
-
do_fork 創建新進程的時候
-
smp_send_reschedule 負載均衡的時候
-
set_user_nice 修改進程 nice 值的時候
以上情況下都會通過 resched_curr 來設置進程 thread_info 結構體裏的 flags 成員爲 TIF_NEED_RESCHED。以 scheduler_tick 和 wake_up_process 爲例：
關於是否需要設置 TIF_NEED_RESCHED 的依據涉及到具體的調度算法，等我們講到具體調度器時再詳細講。
-
2. 執行調度
kernel 判斷當前進程標記是否爲 TIF_NEED_RESCHED，是的話調用 schedule 函數切換上下文，kernel 空間是可以關搶佔的，user 空間是無法關搶佔的。搶佔可分爲內核態搶佔和用戶態搶佔
- 用戶態搶佔
ret_to_user 是系統調用，異常觸發，中斷處理完成後都會調用的函數。
- 內核態搶佔
進程切換上下文 context_switch
通過上面我們知道執行調度的時候發生在 _schedule 函數里。
重點是其中的兩個函數，一個是選擇需要切換任務的 pick_next_task，另外一個是完成進程上下文切換 context_switch。
關於選擇 task 的策略涉及到不同的調度類，等我們講到具體調度器的時候再展開，這裏重點講下上下文切換的函數 context_switch，進程上下文切換主要涉及到兩部分主要過程：進程地址空間切換和處理器狀態切換：
- 進程的地址空間切換
將下一個進程的 pgd 虛擬地址轉化爲物理地址存放在 ttbr0_el1 中 (這是用戶空間的頁表基址寄存器)，當訪問用戶空間地址的時候 mmu 會通過這個寄存器來做遍歷頁表獲得物理地址。完成了這一步，也就完成了進程的地址空間切換，確切的說是進程的虛擬地址空間切換。
- 寄存器狀態切換
其中 x19-x28 是 arm64 架構規定需要調用保存的寄存器，可以看到處理器狀態切換的時候將前一個進程（prev）的 x19-x28，fp,sp,pc 保存到了進程描述符的 cpu_contex 中，然後將即將執行的進程 (next) 描述符的 cpu_contex 的 x19-x28，fp,sp,pc 恢復到相應寄存器中，而且將 next 進程的進程描述符 task_struct 地址存放在 sp_el0 中，用於通過 current 找到當前進程，這樣就完成了處理器的狀態切換。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/GNz4HYZmcI9_oRI0-FJ5qA