LKML Archive on
help / color / mirror / Atom feed
From: Ingo Molnar <>
To: Con Kolivas <>
Cc:, Michael Gerdau <>,
	Nick Piggin <>, Bill Davidsen <>,
	Juliusz Chroboczek <>,
	Mike Galbraith <>,,
	William Lee Irwin III <>,
	Peter Williams <>,
	Gene Heskett <>, Willy Tarreau <>,
	Thomas Gleixner <>,
	Linus Torvalds <>,
	Andrew Morton <>,
	Arjan van de Ven <>
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: <> (raw)
In-Reply-To: <>

* Con Kolivas <> 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.


      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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [ck] Re: [REPORT] cfs-v6-rc2 vs sd-0.46 vs 2.6.21-rc7' \

* 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).