public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: ck@vds.kolivas.org
Cc: Michael Gerdau <mgd@technosis.de>,
	linux-kernel@vger.kernel.org, Nick Piggin <npiggin@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Bill Davidsen <davidsen@tmr.com>,
	Juliusz Chroboczek <jch@pps.jussieu.fr>,
	Mike Galbraith <efault@gmx.de>,
	Peter Williams <pwil3058@bigpond.net.au>,
	William Lee Irwin III <wli@holomorphy.com>,
	Willy Tarreau <w@1wt.eu>, Gene Heskett <gene.heskett@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Arjan van de Ven <arjan@infradead.org>
Subject: Re: [ck] [REPORT] 2.6.21.1 vs 2.6.21-sd046 vs 2.6.21-cfs-v6
Date: Wed, 2 May 2007 22:11:20 +1000	[thread overview]
Message-ID: <200705022211.20769.kernel@kolivas.org> (raw)
In-Reply-To: <200704301005.33884.mgd@technosis.de>

On Monday 30 April 2007 18:05, Michael Gerdau wrote:
> i list,
>
> meanwhile I've redone my numbercrunching tests with the following kernels:
>     2.6.21.1 (mainline)
>     2.6.21-sd046
>     2.6.21-cfs-v6
> running on a dualcore x86_64.
> [I will run the same test with 2.6.21.1-cfs-v7 over the next days,
> likely tonight]

Thanks for testing.

> The tests consist of 3 tasks (named LTMM, LTMB and LTBM). The only
> I/O they do is during init and for logging the results, the rest
> is just floating point math.
>
> There are 3 scenarios:
>     j1 - all 3 tasks run sequentially
> 	 /proc/sys/kernel/sched_granularity_ns=4000000
> 	 /proc/sys/kernel/rr_interval=16
>     j3 - all 3 tasks run in parallel
> 	 /proc/sys/kernel/sched_granularity_ns=4000000
> 	 /proc/sys/kernel/rr_interval=16
>     j3big - all 3 tasks run in parallel with timeslice extended
>             by 2 magnitudes (not run for mainline)
>             /proc/sys/kernel/sched_granularity_ns=400000000
>             /proc/sys/kernel/rr_interval=400
>
> All 3 tasks are run while the system does nothing else except for
> the "normal" (KDE) daemons. The system had not been used for
> interactive work during the tests.
>
> I'm giving user time as provided by the "time" cmd followed by wallclock
> time (all values in seconds).
>
>                 LTMM
>                 j1              j3              j3big
> 2.6.21-cfs-v6    5655.07/ 5682   5437.84/ 5531   5434.04/ 8072
> 2.6.21-sd-046    5556.44/ 5583   5446.86/ 8037   5407.50/ 8274
> 2.6.21.1         5417.62/ 5439   5422.37/ 7132   na     /na
>
>                 LTMB
>                 j1              j3              j3big
> 2.6.21-cfs-v6    7729.81/ 7755   7470.10/10244   7449.16/10186
> 2.6.21-sd-046    7611.00/ 7626   7573.16/10109   7458.10/10316
> 2.6.21.1         7438.31/ 7461   7620.72/11087   na     /na
>
>                 LTBM
>                 j1              j3              j3big
> 2.6.21-cfs-v6    7720.70/ 7746   7567.09/10362   7464.17/10335
> 2.6.21-sd-046    7431.06/ 7452   7539.83/10600   7474.20/10222
> 2.6.21.1         7452.80/ 7481   7484.19/ 9570   na     /na
>
>                 LTMM+LTMB+LTBM
>                 j1              j3              j3big
> 2.6.21-cfs-v6	21105.58/21183  20475.03/26137  20347.37/28593
> 2.6.21-sd-046	20598.50/20661  20559.85/28746  20339.80/28812
> 2.6.21.1	20308.73/20381  20527.28/27789  na      /na
>
>
> User time apparently is subject to some variance. I'm particularly
> surprised by the wallclock time of scenario j1 and j3 for case LTMM with
> 2.6.21-cfs-v6. I'm not sure what to make of this, i.e. whether I had
> happening something else on my machine during j1 of LTMM -- that's always
> been the first test I ran and it might be that there were still some other
> jobs running after the initial boot.
>
> Assuming scenario j1 does constitute the "true" time each task requires and
> also assuming each scheduler makes maximum use of the available CPUs (the
> tests involve very little I/O) one could compute the expected wallclock
> time. However since I suspect the j1 figures of LTMM to be somewhat "dirty"
> I'll refrain from it.
>
> However from these figures it seems as if sd does provide for the fairest
> (as in equal share for all) scheduling among the 3 schedulers tested.

Looks good, thanks. Ingo's been hard at work since then and has v8 out by now. 
SD has not changed so you wouldn't need to do the whole lot of tests on SD 
again unless you don't trust some of the results.

> Best,
> Michael

-- 
-ck

  reply	other threads:[~2007-05-02 12:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-30  8:05 [REPORT] 2.6.21.1 vs 2.6.21-sd046 vs 2.6.21-cfs-v6 Michael Gerdau
2007-05-02 12:11 ` Con Kolivas [this message]
2007-05-03 12:28 ` Ingo Molnar
2007-05-03 12:45   ` Michael Gerdau
  -- strict thread matches above, loose matches on Subject: below --
2007-05-02 23:11 [ck] " Al Boldi
2007-05-03  0:49 ` William Lee Irwin III
2007-05-03  3:51   ` Al Boldi
2007-05-03  4:35     ` William Lee Irwin III
2007-05-03  6:42       ` Al Boldi
2007-05-03  7:23         ` William Lee Irwin III
2007-05-03  8:01           ` Al Boldi

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=200705022211.20769.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --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 \
    /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