LINUX CFS 调度tick逻辑，即check_preemt_tick解析

1. 计算当前task在这个tick周期实际用时delta_exetime, 更新当前task的vruntime;
2. 根据权重，重新计算调度period，计算当前task的应得时间片slice（idle_runtime，实际时间片）；
3. 若delta_exetime大于slice，则设置切换标志；否则继续检查4；
4. 若delta_exetime小于最小调度粒度：0.75ms（sysctl_sched_min_granularity），则不设置切换标志；否则继续检查5；
5. 取出run queue的rq_se（__pick_first_entity），比较curr_se和rq_se的vruntime，若curr_se->vruntime小于rq_se->vruntime，则不设置切换标志，否则继续检查6；
6. 若curr_se->vruntime - rq_se->vruntime 大于 slice, 则设置切换标志；
7. 在中断返回时，进行任务抢占，先通过pick_next_entity找出next，将“即将运行的进程”移出rq，“被抢占的进程”重新加入rq；

为啥第6点直接用 “虚拟时间差值” 与 “实际时间片” 作比较？？？是否会有误差？

----由git log提交信息来看，是为了让nice > 0的进程更容易被抢占，即虚拟时间走得比实际时间快的进程更容易被抢占；

调用schedule tick有两个路径，一个是系统HZ tick，一个hrtimer tick，什么时候会启用hrtimer tick呢？

参考：http://www.wowotech.net/process_management/452.html

内核代码：fair.c -> check_preempt_tick()

即将运行的进程会被移出rq，对应的代码pick_next_task->pick_next_task_fair->set_next_entity->__dequeue_entity

 

总的来说，调度点有两种：

一是curr主动让出cpu，调用schedule，此时next会被移出运行队列，而curr本来就不在rq；

二是tick/中断/异常（系统调用）等，当返回用户空间时，检查抢占标志，进行任务调度；若开启抢占，则返回内核空间时同样可以抢占；