From: Con Kolivas <conman@kolivas.net>
To: Andrew Morton <akpm@digeo.com>
Cc: linux-kernel@vger.kernel.org, riel@conectiva.com.br
Subject: Re: [BENCHMARK] contest results for 2.5.36
Date: Thu, 19 Sep 2002 07:17:48 +1000 [thread overview]
Message-ID: <1032383868.3d88ed7c4cf2d@kolivas.net> (raw)
In-Reply-To: <3D88ACB6.6374E014@digeo.com>
Quoting Andrew Morton <akpm@digeo.com>:
[snip..]
> page_add/remove_rmap. Be interesting to test an Alan kernel too.
Just tell me which ones to test and I'll happily throw them in too.
> > Process Load:
> > Kernel Time CPU
> > 2.4.19 81.10 80%
> > 2.4.20-pre7 81.92 80%
> > 2.5.34 71.39 94%
> > 2.5.36 71.80 94%
>
> Ingo ;)
>
> > Mem Load:
> > Kernel Time CPU
> > 2.4.19 92.49 77%
> > 2.4.20-pre7 92.25 77%
> > 2.5.34 138.05 54%
> > 2.5.36 132.45 56%
>
> The swapping fix in -mm1 may help here.
>
> > IO Halfmem Load:
> > Kernel Time CPU
> > 2.4.19 99.41 70%
> > 2.4.20-pre7 99.42 71%
> > 2.5.34 74.31 93%
> > 2.5.36 94.82 76%
>
> Don't know. Was this with IO load against the same disk as
> the one on which the kernel was being compiled, or a different
> one? This is a very important factor - one way we're testing the
> VM and the other way we're testing the IO scheduler.
My laptop which does all the testing has only one hard disk
> > IO Fullmem Load:
> > Kernel Time CPU
> > 2.4.19 173.00 41%
> > 2.4.20-pre7 146.38 48%
> > 2.5.34 74.00 94%
> > 2.5.36 87.57 81%
>
> If the IO load was against the same disk 2.5 _should_ have sucked,
> due to the writes-starves-reads problem which we're working on. So
> I assume it was against a different disk. In which case 2.5 should not
> have shown these improvements, because all the fixes for this are still
> in -mm. hm. Helpful, aren't I?
It's the same disk. These are the correct values after I've fixed all known
problems in contest. I need someone else to try contest with a different disk.
Helpful? This is all new so it will take a while for _anyone_ to understand
exactly what's going on I'm sure. Since we haven't had incremental benchmarks
till now, who knows what it was that made IO full mem drop from 146 to 74 in the
first place?
Con.
next prev parent reply other threads:[~2002-09-18 21:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-18 14:46 [BENCHMARK] contest results for 2.5.36 Con Kolivas
2002-09-18 16:41 ` Andrew Morton
2002-09-18 16:50 ` Rik van Riel
2002-09-19 8:05 ` Daniel Phillips
2002-09-19 8:14 ` Con Kolivas
2002-09-18 21:17 ` Con Kolivas [this message]
2002-09-18 21:40 ` Andrew Morton
2002-09-18 23:55 ` NMI watchdog stability Jonathan Lundell
2002-09-19 12:07 ` John Levon
2002-09-19 13:20 ` Richard B. Johnson
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=1032383868.3d88ed7c4cf2d@kolivas.net \
--to=conman@kolivas.net \
--cc=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
/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