Messages in this thread Patch in this message | | | Date | Tue, 22 May 2007 14:58:22 +0530 | From | Pranith Kumar D <> | Subject | [PATCH] CFS: sched-design-CFS.txt - ambiguity about leftmost and some formatting |
| |
Hi, The document is very clear and explains the basic mechanism of CFS very well. But, i find that the descriptions are a bit up and down. I mean, u use leftmost and rightmost before mentioning that CFS uses rbtree.( which comes much later).
In the following patch I mentioned the rbtree, the first time you talked about 'leftmost'. Also i did some basic formatting. Hope its not a pain. :)
Signed-off by:Pranith Kumar D<pranith-kumar_d@mentor.com>
--- linux-2.6.21.1//Documentation/sched-design-CFS.txt.orig 2007-05-22 14:33:27.000000000 +0530 +++ linux-2.6.21.1//Documentation/sched-design-CFS.txt 2007-05-22 14:46:38.000000000 +0530 @@ -1,20 +1,20 @@
-this is the CFS scheduler. +This is the CFS scheduler.
80% of CFS's design can be summed up in a single sentence: CFS basically models an "ideal, precise multi-tasking CPU" on real hardware.
-"Ideal multi-tasking CPU" is a (non-existent :-) CPU that has 100% +"Ideal multi-tasking CPU" is a (non-existent :-)) CPU that has 100% physical power and which can run each task at precise equal speed, in parallel, each at 1/nr_running speed. For example: if there are 2 tasks running then it runs each at 50% physical power - totally in parallel.
On real hardware, we can run only a single task at once, so while that -one task runs the other tasks that are waiting for the CPU are at a +one task runs, the other tasks that are waiting for the CPU are at a disadvantage - the current task gets an unfair amount of CPU time. In CFS this fairness imbalance is expressed and tracked via the per-task p->wait_runtime (nanosec-unit) value. "wait_runtime" is the amount of -time the task should now run on the CPU for it become completely fair +time the task should now run on the CPU for it to become completely fair and balanced.
( small detail: on 'ideal' hardware, the p->wait_runtime value would @@ -37,10 +37,10 @@ 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 -current task is preempted. +task becomes the 'leftmost task' of the time-ordered rbtree it maintains +(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 current task is preempted.
The rq->fair_clock value tracks the 'CPU time a runnable task would have fairly gotten, had it been runnable during that time'. So by using @@ -64,7 +64,7 @@ Some implementation details: replacement for the vanilla scheduler's SCHED_OTHER interactivity code.
- i'd like to give credit to Con Kolivas for the general approach here: + I'd like to give credit to Con Kolivas for the general approach here: he has proven via RSDL/SD that 'fair scheduling' is possible and that it results in better desktop scheduling. Kudos Con!
@@ -92,17 +92,17 @@ Some implementation details: setting suitable for desktop workloads. SCHED_BATCH is handled by the CFS scheduler module too.
- due to its design, the CFS scheduler is not prone to any of the + Due to its design, the CFS scheduler is not prone to any of the 'attacks' that exist today against the heuristics of the stock scheduler: fiftyp.c, thud.c, chew.c, ring-test.c, massive_intr.c all work fine and do not impact interactivity and produce the expected behavior.
- the CFS scheduler has a much stronger handling of nice levels and + The CFS scheduler has a much stronger handling of nice levels and SCHED_BATCH: both types of workloads should be isolated much more agressively than under the vanilla scheduler.
- ( another rdetail: due to nanosec accounting and timeline sorting, + ( another detail: due to nanosec accounting and timeline sorting, sched_yield() support is very simple under CFS, and in fact under CFS sched_yield() behaves much better than under any other scheduler i have tested so far. )
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |