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


* Con Kolivas <kernel@kolivas.org> wrote:

> > as a summary: i think your numbers demonstrate it nicely that the
> > shorter 'timeslice length' that both CFS and SD utilizes does not have a
> > measurable negative impact on your workload. To measure the total impact
> > of 'timeslicing' you might want to try the exact same workload with a
> > much higher 'timeslice length' of say 400 msecs, via:
> >
> >     echo 400000000 > /proc/sys/kernel/sched_granularity_ns  # on CFS
> >     echo 400 > /proc/sys/kernel/rr_interval                 # on SD
> 
> I thought that the effective "timeslice" on CFS was double the 
> sched_granularity_ns so wouldn't this make the effective timeslice 
> double that of what you're setting SD to? [...]

The two settings are not really comparable. The "effective timeslice is 
the double of the granularity" thing i mentioned before is really a 
special-case: only true for a really undisturbed 100% CPU-using 
_two-task_ workload, if and only if the workload would not reschedule 
otherwise, but that is clearly not the case here: and if you look at the 
vmstat output provided by Michael you'll see that all 3 schedulers 
rescheduled this workload at around 1000/sec or 1 msec per scheduling 
atom. (But i'd agree that to be on the safe side the context-switch rate 
has to be monitored and if it seems too high on SD, the rr_interval 
should be increased.)

> [...] Anyway the difference between 400 and 800ms timeslices is 
> unlikely to be significant so I don't mind.

even on a totally idle system there's at least a 10 Hz 'background 
sound' of various activities, so any setting above 100 msecs rarely has 
any effect.

	Ingo

      parent reply	other threads:[~2007-04-27  6:53 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
2007-04-26 22:59   ` [ck] " Con Kolivas
2007-04-27  5:59     ` Michael Gerdau
2007-04-27  6:52     ` Ingo Molnar [this message]

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=20070427065204.GA31708@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=kernel@kolivas.org \
    --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: [ck] 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).