LINUX CFS 调度tick逻辑,即check_preemt_tick解析
2024-09-01 04:29:26
- 计算当前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/中断/异常(系统调用)等,当返回用户空间时,检查抢占标志,进行任务调度;若开启抢占,则返回内核空间时同样可以抢占;
最新文章
- shell-script的简单举例
- 《阿Q正传》读后感
- RGB颜色表
- opencv 处女作
- 算法与数据结构之顺序查找(C语言)
- 扩展ViewFlow避免和ViewPager滑动冲突,同时支持无限循环,并完美和CircleFlowIndicator结合
- Web体系=资源+URI+表示
- (一)初探HTML!
- BZOJ2105: 增强型LCP
- OCP-1Z0-042-V12.39-47题
- AJAX(XMLHttpRequest)进行跨域请求方法详解(二)
- Logcat过滤及常见用法整理
- iOS 通过UIControl,自定义控件
- zabbix源码安装 令人窒息的操作
- 锁(1):spin_lock &; mutex_lock的区别? .
- Matlab:导数边界值的有限元(Galerkin)法
- springboot整合mybatis之注解方式
- 【PAT】B1070 结绳(25 分)
- openjudge noi 鸡尾酒疗法
- Windows下PythonQt编译(vs2015+Qt5.11.2+PythonQt 3.2)探索