public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Daniel Walker <dwalker@mvista.com>,
	linux-kernel@vger.kernel.org, peterz@infradead.org
Subject: Re: [ANNOUNCE/RFC] Really Fair Scheduler
Date: Sun, 2 Sep 2007 17:29:00 +0200	[thread overview]
Message-ID: <20070902152900.GA23642@elte.hu> (raw)
In-Reply-To: <Pine.LNX.4.64.0709021655340.1817@scrub.home>


* Roman Zippel <zippel@linux-m68k.org> wrote:

> > And if you look at the resulting code size/complexity, it actually 
> > increases with Roman's patch (UP, nodebug, x86):
> > 
> >      text    data     bss     dec     hex filename
> >     13420     228    1204   14852    3a04 sched.o.rc5
> >     13554     228    1228   15010    3aa2 sched.o.rc5-roman
> 
> That's pretty easy to explain due to differences in inlining:
> 
>    text    data     bss     dec     hex filename
>   15092     228    1204   16524    408c kernel/sched.o
>   15444     224    1228   16896    4200 kernel/sched.o.rfs
>   14708     224    1228   16160    3f20 kernel/sched.o.rfs.noinline

no, when generating those numbers i used:

  CONFIG_CC_OPTIMIZE_FOR_SIZE=y
  # CONFIG_FORCED_INLINING is not set

(but i also re-did it for all the other combinations of these build 
flags and similar results can be seen - your patch, despite removing 
lots of source code, produces a larger sched.o.)

> Sorry, but I didn't spend as much time as you on tuning these numbers.

some changes did slip into your patch that have no other purpose but to 
reduce code size:

  +#ifdef CONFIG_SMP
          unsigned long cpu_load[CPU_LOAD_IDX_MAX];
  +#endif
  [...]
  +#ifdef CONFIG_SMP
   /* Used instead of source_load when we know the type == 0 */
   unsigned long weighted_cpuload(const int cpu)
   {
          return cpu_rq(cpu)->ls.load.weight;
   }
  +#endif
  [...]

so i thought you must be aware of the problem - at least considering how 
much you've criticised CFS's "complexity" both in your initial review of 
CFS (which included object size comparisons) and in this patch 
submission of yours (which did not include object size comparisons
though).

> > so unmodified CFS is 4.6% faster on this box than with Roman's patch 
> > and it's also more consistent/stable (10 times lower fluctuations).
> 
> Was SCHED_DEBUG enabled or disabled for these runs?

debugging disabled of course. (your patch has a self-validity checking 
function [verify_queue()] that is called on SCHED_DEBUG=y, it would have 
been unfair to test your patch with that included.)

	Ingo

  reply	other threads:[~2007-09-02 15:29 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-31  2:05 [ANNOUNCE/RFC] Really Fair Scheduler Roman Zippel
2007-08-31  9:36 ` Mike Galbraith
2007-08-31 13:22   ` Roman Zippel
2007-08-31 13:55     ` Mike Galbraith
2007-09-01  4:35     ` Mike Galbraith
2007-08-31 10:54 ` Ingo Molnar
2007-08-31 13:19   ` Roman Zippel
2007-09-02  9:26     ` Ingo Molnar
2007-09-03  2:58       ` Roman Zippel
2007-09-06  3:03         ` Syren Baran
2007-09-01  6:48   ` Roman Zippel
2007-09-02  2:19     ` Bill Davidsen
2007-09-02 17:02       ` Roman Zippel
2007-09-02  0:52 ` Daniel Walker
2007-09-02  7:20   ` Ingo Molnar
2007-09-02  8:40     ` Satyam Sharma
2007-09-02  9:59       ` Ingo Molnar
2007-09-02 15:16     ` Roman Zippel
2007-09-02 15:29       ` Ingo Molnar [this message]
2007-09-02 17:16         ` Roman Zippel
2007-09-02 19:21           ` Ingo Molnar
2007-09-07 15:35     ` Roman Zippel
2007-09-08  7:56       ` Mike Galbraith
2007-09-08  8:23         ` Mike Galbraith
2007-09-10 23:23         ` Roman Zippel
2007-09-11  6:18           ` Mike Galbraith
2007-09-11 11:28             ` Roman Zippel
2007-09-02 14:47   ` Roman Zippel
2007-09-02 15:00     ` Daniel Walker
2007-09-03 18:20       ` Roman Zippel
2007-09-03 21:06         ` Daniel Walker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070902152900.GA23642@elte.hu \
    --to=mingo@elte.hu \
    --cc=dwalker@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=zippel@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox