* Satyam Sharma <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
