- 计算当前task在这个tick周期实际用时delta_exetime, 更新当前task的vruntime;
- 根据权重,重新计算调度period,计算当前task的应得时间片slice(idle_runtime,实际时间片);
- 若delta_exetime大于slice,则设置切换标志;否则继续检查4;
- 若delta_exetime小于最小调度粒度:0.75ms(sysctl_sched_min_granularity),则不设置切换标志;否则继续检查5;
- 取出run queue的rq_se(__pick_first_entity),比较curr_se和rq_se的vruntime,若curr_se->vruntime小于rq_se->vruntime,则不设置切换标志,否则继续检查6;
- 若curr_se->vruntime - rq_se->vruntime 大于 slice, 则设置切换标志;
- 在中断返回时,进行任务抢占,先通过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/中断/异常(系统调用)等,当返回用户空间时,检查抢占标志,进行任务调度;若开启抢占,则返回内核空间时同样可以抢占;