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.
sysctl_sched_latency
time?place_entity
function? vruntime
adjusted by subtracting from sched_latency
? Can't that lead to processes in the run queue with large differences in the vruntime
value?Firstly the virtual runtime of a task
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With