LKML Archive on
help / color / mirror / Atom feed
From: Ingo Molnar <>
To: Con Kolivas <>
Cc: linux list <>,
	Andrew Morton <>,
	Mike Galbraith <>
Subject: [test] hackbench.c interactivity results: vanilla versus SD/RSDL
Date: Thu, 29 Mar 2007 13:22:49 +0200	[thread overview]
Message-ID: <> (raw)

* Ingo Molnar <> wrote:

> * Con Kolivas <> wrote:
> > I'm cautiously optimistic that we're at the thin edge of the bugfix 
> > wedge now.

> and the numbers he posted:
> his test conclusion was that under CPU load, RSDL (SD) generally does 
> not hold up to mainline's interactivity.

Today i've done some hackbench.c (which is similar to VolanoMark) 
interactivity testing on SD-latest (v0.37), doing "hackbench 10", 
"hackbench 50" and "hackbench 100" runs, comparing it to 


performance was largely comparable, within noise: the vanilla scheduler 
was slightly (~5%) better at "hackbench 10", SD and vanilla was within 
noise on "hackbench 50" and "hackbench 100" runs. (I think vanilla's 
better results might be due to the longer timeslices vanilla can give 
out - SD has to operate via short timeslices, by design.)

Shell interactivity

The vanilla scheduler kept the shell completely usable during all tests: 
'ls' output was instantaneous and characters could be typed without 

The SD/RSDL scheduler kept the shell barely usable during the hackbench 
10 test, and it was completely unusable during the hackbench 50 and 100 
tests. A simple 'ls' took 2-3 seconds to complete (up to 6 seconds at 
times) and the shell printed characters in a very laggy way. 'vi' was 
totally unusable, etc. etc.

[ i've also re-tested this with RSDL 0.34, and there interactivity got 
  better although it still didnt match that of the vanilla scheduler's
  interactivity. So this is a definitive SD regression. ]

[ A quick guess: could SD's substandard interactivity in this test be 
  due to the SMP migration logic inconsistencies Mike noticed? This is 
  an SMP system and the hackbench workload is very scheduling intense 
  and tasks are frequently queued from one CPU to another. ]


i consider this a must-fix item as SD badly misbehaves under this 

Test environment details

the test system is a 2GHz Athlon64 dual-core box. All tests were running 
on default nice 0 levels. All tests were done 10 times on a totally idle 
test-system. Mike's patch is the one that improves vanilla scheduler's 
anti-starvation code:

( Mike's patch does not make a measurable performance difference in
  hackbench, nor does it make a visible interactivity difference for 
  this workload, but since i think Mike's patch improves the vanilla 
  scheduler i included it in the test for completeness, so that both 
  variants of interactivity code are at the 'bleeding edge'. )


             reply	other threads:[~2007-03-29 11:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-29 11:22 Ingo Molnar [this message]
2007-04-03  1:07 ` [test] hackbench.c interactivity results: vanilla versus SD/RSDL Con Kolivas
2007-03-30 15:05 Xenofon Antidides
2007-03-30 16:46 ` Mike Galbraith
2007-03-31  2:36   ` Xenofon Antidides
2007-03-31  3:23     ` Mike Galbraith
2007-03-31  3:42       ` Mike Galbraith
2007-03-31  6:08         ` Mike Galbraith
2007-03-31  5:41       ` Xenofon Antidides
2007-03-31  6:31         ` Mike Galbraith
2007-03-31  6:49           ` Mike Galbraith
2007-03-31  9:28           ` Xenofon Antidides
2007-03-31  9:43             ` Ingo Molnar
2007-03-31 10:05             ` Ingo Molnar
2007-04-03  2:34             ` Con Kolivas
2007-04-03  5:24               ` Mike Galbraith
2007-03-31  5:04 ` Nick Piggin

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 \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).