[lkml]   [2007]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ANNOUNCE/RFC] Really Fair Scheduler

    * Satyam Sharma <> wrote:

    > On Sun, 2 Sep 2007, Ingo Molnar wrote:
    > >
    > > Although it _should_ have been a net code size win, because if you
    > > look at the diff you'll see that other useful things were removed as
    > > well: sleeper fairness, CPU time distribution smarts, tunings,
    > > scheduler instrumentation code, etc.
    > To be fair to Roman, he probably started development off an earlier
    > CFS, most probably 2.6.23-rc3-git1, if I guess correctly from his
    > original posting. So it's likely he missed out on some of the
    > tunings/comments(?) etc code that got merged after that.

    actually, here are the rc3->rc5 changes to CFS:

    sched.c | 89 ++++++++++++++++++++++++------------
    sched_debug.c | 3 -
    sched_fair.c | 142 +++++++++++++++++++++++++++++++++++++++++++++-------------
    sched_rt.c | 11 +++-
    4 files changed, 182 insertions(+), 63 deletions(-)

    so since -rc3 CFS's size _increased_ (a bit).

    and i just checked, the sched.o codesize still increases even when
    comparing rc4 against rc4+patch (his original patch) and there are no
    comments added by Roman's patch at all. (all the comments in
    sched_norm.c were inherited from sched_fair.c and none of the new code
    comes with comments - this can be seen in Daniel's rediffed patch.)

    (and it's still not apples to oranges, for the reasons i outlined - so
    this whole comparison is unfair to CFS on several levels.)

    also, note that CFS's modularity probably enabled Roman to do a fairly
    stable kernel/sched_norm.c (as most of the post-rc3 CFS changes were not
    to sched.c but to sched_fair.c) with easy porting. So with the CFS
    modular framework you can easily whip up and prototype a new scheduler
    and name it whatever you like. [ i expect the RCFS (Really Completely
    Fair Scheduler) patches to be posted to lkml any minute ;-) ]

    > > It would be far more reviewable and objectively judgeable on an item
    > > by item basis if Roman posted the finegrained patches i asked for.
    > > (which patch series should be sorted in order of intrusiveness -
    > > i.e. leaving the harder changes to the end of the series.)
    > Absolutely. And if there indeed are net improvements (be it for corner
    > cases) over latest CFS-rc5, while maintaining performance for the
    > common cases at the same time, well, that can only be a good thing.

    yeah - and as i said to Roman, i like for example the use of a
    ready-queue instead of a run-queue. (but these are independent of the
    math changes, obviously.)

    I also think that the core math changes should be split from the
    Breshenham optimizations. I.e. the Breshenham _fract code should be done
    as a "this improves performance and improves rounding, without changing
    behavior" add-on ontop of a fairly simple core math change. I think
    Roman will easily be able to do this with a few hours of effort which
    should present much reduced .text overhead in his next version of the
    patch, to demonstrate the simplicity of his implementation of the CFS
    fairness math - this really isnt hard to do.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-09-02 12:03    [W:0.022 / U:46.520 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site