LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Michael Gerdau <mgd@technosis.de>
Cc: linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Nick Piggin <npiggin@suse.de>,
	Gene Heskett <gene.heskett@gmail.com>,
	Juliusz Chroboczek <jch@pps.jussieu.fr>,
	Mike Galbraith <efault@gmx.de>,
	Peter Williams <pwil3058@bigpond.net.au>,
	ck list <ck@vds.kolivas.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	William Lee Irwin III <wli@holomorphy.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Bill Davidsen <davidsen@tmr.com>, Willy Tarreau <w@1wt.eu>,
	Arjan van de Ven <arjan@infradead.org>
Subject: Re: [REPORT] cfs-v6-rc2 vs sd-0.46 vs 2.6.21-rc7
Date: Thu, 26 Apr 2007 15:55:09 +0200	[thread overview]
Message-ID: <20070426135509.GA29832@elte.hu> (raw)
In-Reply-To: <200704261522.43347.mgd@technosis.de>


* Michael Gerdau <mgd@technosis.de> wrote:

> In general sd tends to finish all three such jobs at roughly the same 
> time while cfs clearly "favors" the LTMM-type jobs (which admittedly 
> involve the least computations). I don't really know why that is so.

for the reason of this, look at the raw user runtimes the 3 jobs have:

  5498.128  secs            # LTMM
  7559.777  secs
  7600.179  secs

the "perfect scheduler" would run each of the jobs at 33.33% of capacity 
for ~5500 CPU-seconds, and would then run the remaining two jobs at 
50.0% capacity for about ~2075 CPU-seconds.

Why? Because the scheduler how no idea how much each job takes! So a 
fair scheduler would run: 3 jobs at 33.33% capacity for as long as the 
shortest job ends, then the remaining 2 jobs at 50% capacity for as the 
shorter one of the remaining 2 finishes, and the remaining one at 100%.

in your case that means that the best scheduling would be roughly the 
following ideal timeline:

   5500*3 / 2 ==  8250 seconds for the LTMM to finish
   2075*2 / 2 == +2075 more seconds for the other two jobs to finish.

the various runs showed the following wallclock-time timeline for the 
LTMM phase:

   CFS #1:  real    142m56.806s
   CFS #2:  real    125m58.235s
   SD:      real    140m16.127s
   vanilla: real    133m50.274s

the "ideal" is ~137 minutes (8250 seconds) for the LTMM phase. The 
closest was indeed SD, but vanilla and cfs #1 wasnt too far away from it 
either. [ and the variance between CFS #1 and #2 seems to suggest that 
the noise of this particular metric is significant. The average does 
come in at 134.5, which is quite close to the ideal number. ]

	Ingo

  reply	other threads:[~2007-04-26 13:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-26 11:12 Michael Gerdau
2007-04-26 12:07 ` Ingo Molnar
2007-04-26 13:22   ` Michael Gerdau
2007-04-26 13:55     ` Ingo Molnar [this message]
2007-04-26 22:59   ` [ck] " Con Kolivas
2007-04-27  5:59     ` Michael Gerdau
2007-04-27  6:52     ` Ingo Molnar

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=20070426135509.GA29832@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=ck@vds.kolivas.org \
    --cc=davidsen@tmr.com \
    --cc=efault@gmx.de \
    --cc=gene.heskett@gmail.com \
    --cc=jch@pps.jussieu.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgd@technosis.de \
    --cc=npiggin@suse.de \
    --cc=pwil3058@bigpond.net.au \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=w@1wt.eu \
    --cc=wli@holomorphy.com \
    --subject='Re: [REPORT] cfs-v6-rc2 vs sd-0.46 vs 2.6.21-rc7' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).