linux-kernel - [PATCH] CFS: sched-design-CFS.txt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 May 2007 12:20:24 +0530
From:	Pranith Kumar D <pranith-kumar_d@...tor.com>
To:	mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: [PATCH] CFS: sched-design-CFS.txt - ambiguity about leftmost

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<pranith-kumar_d@...torg.com>

--- 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/