调用sleep后，我做了一个噩梦

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。