From: Andrew Morton <akpm@digeo.com>
To: Aniruddha M Marathe <aniruddha.marathe@wipro.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [BENCHMARK] Lmbench 2.5.54-mm2 (impressive improvements)
Date: Fri, 03 Jan 2003 01:33:55 -0800 [thread overview]
Message-ID: <3E155903.F8C22286@digeo.com> (raw)
In-Reply-To: 94F20261551DC141B6B559DC4910867204491F@blr-m3-msg.wipro.com
Aniruddha M Marathe wrote:
>
> Here is a comparison of results of 2.5.54 with mm2 and 2.5.54.
I'm sorry, but all you are doing with these tests is discrediting
lmbench, AIM9, tiobench and unixbench. There really is nothing in
these patches which can account for the changes which you are observing.
Possibly, it is all caused by cache colouring effects - the physical
addresses at which critical kernel and userspace text and data
happen to end up.
I'd suggest that you look for more complex tests. There's a decent
list at http://lbs.sourceforge.net/, but even those are rather microscopic.
If you have time, things like the osdl dbt1 test, http://osdb.sourceforge.net/
and the commercial benchmarks would be more interesting.
Or cook up some of your own: it's not hard. Just think of some time-consuming
operation which we perform on a daily basis and measure it. Script
the startup and shutdown of X11 applications. rsync. sendmail. cvs.
Mixed workloads are interesting and real world: run tiobench or dbench
or qsbench or whatever while trying to do something else, see how long
"something else" takes.
It is these sorts of things which will find areas of weakness which
can be addressed in this phase of kernel development.
The teeny little microbenchmarks are telling us that the rmap overhead
hurts, that the uninlining of copy_*_user may have been a bad idea, that
the addition of AIO has cost a little and that the complexity which
yielded large improvements in readv(), writev() and SMP throughput were
not free. All of this is already known.
next prev parent reply other threads:[~2003-01-03 9:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-03 8:59 [BENCHMARK] Lmbench 2.5.54-mm2 (impressive improvements) Aniruddha M Marathe
2003-01-03 9:33 ` Andrew Morton [this message]
2003-01-03 10:24 ` David S. Miller
2003-01-03 10:22 ` Andrew Morton
[not found] <94F20261551DC141B6B559DC4910867204491F@blr-m3-msg.wipro.com.suse.lists.linux.kernel>
[not found] ` <3E155903.F8C22286@digeo.com.suse.lists.linux.kernel>
2003-01-03 18:40 ` Andi Kleen
2003-01-03 21:32 ` Andrew Morton
2003-01-05 1:01 ` Andrew Morton
2003-01-05 3:35 ` Linus Torvalds
2003-01-05 3:51 ` Linus Torvalds
2003-01-05 3:54 ` Andrew Morton
2003-01-05 3:52 ` Linus Torvalds
2003-01-05 10:06 ` Andi Kleen
2003-01-05 18:51 ` Linus Torvalds
2003-01-05 23:46 ` Andi Kleen
2003-01-06 1:33 ` Linus Torvalds
2003-01-06 2:05 ` Andi Kleen
2003-01-06 0:58 ` H. Peter Anvin
2003-01-05 9:18 ` Andrew Morton
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=3E155903.F8C22286@digeo.com \
--to=akpm@digeo.com \
--cc=aniruddha.marathe@wipro.com \
--cc=linux-kernel@vger.kernel.org \
/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