Linux CFS（完全公平调度程序）延迟
我是 Linux 内核的初学者，我正在尝试了解 Linux 如何调度进程。
我读过一些有关 Linux 内核的书籍，并浏览了 IBM http://www.ibm .com/developerworks/linux/library/l-cfs/ 等等，但我仍然有一些疑问。
- 调度程序如何在 sysctl_sched_latency 时间内调度所有任务？
- 当进程唤醒时，
place_entity函数实际上做了什么？ - 当进程唤醒时，为什么要通过从
sched_latency中减去来调整vruntime？这会不会导致运行队列中的进程的vruntime值差异较大？
I am a beginner to the Linux Kernel and I am trying to learn how Linux schedules processes.
I have read some books on the Linux Kernel and gone through the links from IBM http://www.ibm.com/developerworks/linux/library/l-cfs/ and all, but I am still left with some doubts.
- How does the scheduler schedule all of the tasks within the
sysctl_sched_latencytime? - When a process wakes up what actually is done in the
place_entityfunction? - When a process wakes up why is the
vruntimeadjusted by subtracting fromsched_latency? Can't that lead to processes in the run queue with large differences in thevruntimevalue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，任务的虚拟运行时间
在理论上完美的多线程 CPU 上执行。
1。调度程序如何调度所有任务
sysctl_sched_latency时间？
它维护了一个时间有序的红黑树，其中所有可运行的任务都在
按虚拟运行时排序。左侧的节点运行时间最短。
CFS 选择最左边的任务并运行它，直到任务调度或调度程序勾选
然后它运行所花费的CPU时间被添加到它的虚拟运行时。
当它不再是最左边的节点时，则运行具有最短虚拟的新任务并
旧任务已完成。
2.当进程唤醒时，place_entity 函数实际上做了什么？
简短版本：
当进程唤醒时，place_entity 函数要么离开
任务的虚拟运行时保持原样或增加。
长版本：
当进程唤醒时，place_entity 函数会执行以下操作
将临时虚拟运行时初始化为 CFS 运行队列的最小任务的虚拟运行时。
由于睡眠时间少于单个延迟时间，因此不算在内，
将阈值变量初始化为 sysctl_sched_latency。
如果启用了 GENTLE_FAIR_SLEEPERS 功能，
然后是 this 变量值的一半。
将之前初始化的临时虚拟运行时减少此阈值。
通过将计算出的虚拟运行时设置为自身和任务虚拟运行时的最大值，确保临时虚拟运行时至少等于任务的虚拟运行时。
将任务的虚拟运行时设置为临时运行时。
3.当进程唤醒时，为什么要通过从 sched_latency 中减去来调整 vruntime？
虚拟运行时会递减，因为睡眠时间少于单个延迟不计算在内。
例如，如果任务已更改，则不应更改其在红黑树中的位置
仅休眠单个调度程序延迟。
4.难道这不会导致运行队列中的进程在 vruntime 值上存在较大差异吗？
我相信问题 2 的步骤 3 中描述的逻辑可以防止或至少最大限度地减少这种情况。
参考资料
sched Linux 内核源码
sched_fair.c Linux 内核来源
CFS 调度程序设计说明
Firstly the virtual runtime of a task
execution on a theoretically perfect multiple threaded CPU.
1. How does the scheduler schedule all of the tasks within the
sysctl_sched_latency time?
It maintains a time ordered red and black tree, where all the runnable tasks are
sorted by their virtual runtime. Nodes on the left have run for the shortest amount of time.
CFS picks the left most task and runs it, until the task schedules or the scheduler ticks
then the CPU time it spent running is added to its virtual runtime.
When it is no longer the left most node, then new task with the shortest virtual is run and
the old task prempted.
2. When a process wakes up what actually is done in the place_entity function?
Short version:
When a process wakes up the place_entity function either leaves the
task's virtual runtime as it was or increases it.
Long version:
When a process wakes up the place_entity function does the following things
Initialise the temporary virtual runtime to the CFS run queue's virtual runtime of the smallest task.
As sleeps less than a single latency don't count,
initializses a threshold variable to sysctl_sched_latency.
If the GENTLE_FAIR_SLEEPERS feature is enabled,
then half the value of the this variable.
Decrement the previously initialised temporary virtual runtime by this threshold value.
Ensure that the temporary virtual runtime is at least equal to the task's virtual runtime, by setting the calculated virtual runtime to the maximum of itself and the task's virtual runtime.
Set the task's virtual runtime to the temporary runtime.
3. When a process wakes up why is the vruntime adjusted by subtracting from sched_latency?
The virtual runtime is decremented because sleeps less than a single latency don't count.
E.g the task shouldn't have its position changed in the red black tree changed if it has
only slept for a single scheduler latency.
4. Can't that lead to processes in the run queue with large differences in the vruntime value?
I believe that the logic described in Step 3 for Question 2, prevents or at least minimises that.
References
sched Linux Kernel Source
sched_fair.c Linux Kernel Source
Notes on the CFS Scheduler Design