Hello,
I felt the description of the leftmost task a bit ambiguous. Is it the
leftmost task in the rbtree?
or did u mean the "most leftout task" in the task list? If it is so then
this patch should correct the leftmost task as "most leftout task". NACK
it if I'm wrong. Just trying to help. :)
Changes "leftmost task" to "most leftout task".
Signed-off by: Pranith Kumar D<[email protected]>
--- sched-design-CFS.txt.orig 2007-05-22 12:04:43.000000000 +0530
+++ sched-design-CFS.txt 2007-05-22 12:11:35.000000000 +0530
@@ -37,9 +37,9 @@ the task schedules (or a scheduler tick
'accounted for': the (small) time it just spent using the physical CPU
is deducted from p->wait_runtime. [minus the 'fair share' it would have
gotten anyway]. Once p->wait_runtime gets low enough so that another
-task becomes the 'leftmost task' (plus a small amount of 'granularity'
-distance relative to the leftmost task so that we do not over-schedule
-tasks and trash the cache) then the new leftmost task is picked and the
+task becomes the 'most leftout task' (plus a small amount of 'granularity'
+distance relative to the most leftout task so that we do not over-schedule
+tasks and trash the cache) then the new most leftout task is picked and the
current task is preempted.
The rq->fair_clock value tracks the 'CPU time a runnable task would have
@@ -47,10 +47,10 @@ fairly gotten, had it been runnable duri
rq->fair_clock values we can accurately timestamp and measure the
'expected CPU time' a task should have gotten. All runnable tasks are
sorted in the rbtree by the "rq->fair_clock - p->wait_runtime" key, and
-CFS picks the 'leftmost' task and sticks to it. As the system progresses
+CFS picks the 'most leftout' task and sticks to it. As the system
progresses
forwards, newly woken tasks are put into the tree more and more to the
right - slowly but surely giving a chance for every task to become the
-'leftmost task' and thus get on the CPU within a deterministic amount of
+'most leftout task' and thus get on the CPU within a deterministic
amount of
time.
Some implementation details:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]