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

* Satyam Sharma <satyam@infradead.org> 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.

Ingo

-
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-09-02 12:03    [from the cache]
©2003-2011 Jasper Spaans