lkml.org 
[lkml]   [2007]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    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/

    \
     
     \ /
      Last update: 2007-05-22 11:31    [W:2.289 / U:23.188 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site