調用sleep後，我做了一個噩夢

2020 年 4 月 23 日
筆記

sleep系統調用

我是一個線程，生活在Linux帝國。一直以來辛勤工作，日子過得平平淡淡，可今天早上發生了一件事讓我回想起來都後怕。

早上，我還是如往常一樣執行着人類編寫的代碼指令，不多時走到了一個冷門的分支，一個sleep()函數調用擺在了我的面前。

終於可以去休息了！聽老一輩的線程們說，執行了這個函數就可以休息休息了。我瞄了一眼參數，足足有5秒鐘的休息時間，我簡直樂壞了，沒有猶豫，趕緊執行了這個調用。

進入sleep()函數後，又來到了nano_sleep()函數，接着看到了一個syscall系統調用指令，我繼續執行，來到了內核空間。

進入內核空間後，我接連穿過了

–> nano_sleep()
–> hrtimer_nanosleep()
–> do_nanosleep()
–> freezable_schedule()

把我累得夠嗆，說好讓我休息，沒想到休息之前還有這麼多事要做。

終於，我來到了一個叫schedule()的函數面前。

線程調度

進入schedule()後，迎面走來一位發須皆已花白的長者。

「小夥子，這是要來休息了，我是負責線程調度的使者，讓我看下你佔用的CPU號碼」，一邊說一邊查找着什麼。

「哦，是2號CPU，來，跟我到這邊來」，在他的指引下，我又來到了一個函數面前。

「你先去pick_next_task()找到一個接盤俠，哦不，找到下一個需要執行的線程，這是2號CPU的就緒隊列，你可拿好了，等你辦完回來我再帶你去辦理交接手續」，說完給我手裡塞了一個參數rq，隨即便離開了，留下我不知所措。

我只好按他說的照辦，邁進了pick_next_task()函數的大門，一位美女接待映入眼帘。

「先生您好，您來此想必是要尋找接班線程吧」，見我到來，美女起身招呼。

「你猜的不錯，要麻煩你幫我處理一下，多謝了」

「您別客氣，把就緒隊列給我看看吧」

我先是愣了一下，反應過來後將手裡的rq參數給了她。

struct rq {
    raw_spinlock_t lock;
    ...
    unsigned int nr_running;
    ...
    struct cfs_rq cfs;
    struct rt_rq rt;
    struct dl_rq dl;
    ...
    struct task_struct *curr, *idle, *stop;
    ...
    struct mm_struct *prev_mm;
    ...
    struct list_head cfs_tasks;
};

美女拿着rq一陣端詳，說到：「您運氣不錯哦，rq->nr_running和rq->cfs.h_nr_running相等，看來沒有實時線程，全是普通線程，您直接去那邊的公平調度CFS窗口fair_sched_class那裡去辦理吧。」

我順着美女指向的方向看去，那邊一共有5個窗口：

stop_sched_class
dl_sched_class
rt_sched_class
fair_sched_class
idle_sched_class

「唉，美女，那要是不相等該去哪個窗口辦理呢？你告訴我一下，下次來我就知道了」

「不相等的話那就說明就緒隊列里除了普通線程還有其他優先級更高的線程，就得按照優先級從stop_sched_class窗口挨個向後詢問，直到找到一個線程。不過我在這幹了這麼久，就實時線程所在的rt_sched_class窗口和普通線程所在的fair_sched_class最常用」，美女耐心的給我解釋到。

聽了她的解釋，我想到了一個問題：「那要是都找不到線程需要執行怎麼辦，比如他們都在等待IO事件之類的？那我怎麼交差啊」

「放心吧，最後那個idle_sched_class窗口絕對不會讓你空手而歸的」，美女笑着說。

原來如此，我點了點頭。

來到fair_sched_class窗口的旁邊，遞交了我的rq參數，只見工作人員取出了其中的cfs_rq：

struct cfs_rq {
	struct load_weight load;
	unsigned int nr_running, h_nr_running;
	...
	struct rb_root tasks_timeline;
	struct rb_node *rb_leftmost;
	...
	struct sched_entity *curr, *next, *last, *skip;
	...
	struct rq *rq;
};

我這才注意到，原來這個cfs_rq中指向了一棵紅黑樹，再仔細一看，這樹上的每個節點都是一個線程task_struct。