From: Theodore Tso <tytso@mit.edu>
To: Andrew Morton <akpm@zip.com.au>
Cc: Daniel Phillips <phillips@bonn-fries.net>,
Marcelo Tosatti <marcelo@conectiva.com.br>,
linux-mm@kvack.org, Rik van Riel <riel@conectiva.com.br>,
Linus Torvalds <torvalds@transmeta.com>,
Mike Galbraith <mikeg@wen-online.de>,
Steven Cole <elenstev@mesatop.com>,
Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
Subject: Re: 2.4.8-pre1 and dbench -20% throughput
Date: Sun, 29 Jul 2001 23:19:20 -0400 [thread overview]
Message-ID: <20010729231920.A10320@thunk.org> (raw)
In-Reply-To: <3B6369DE.F9085405@zip.com.au>; from akpm@zip.com.au on Sun, Jul 29, 2001 at 11:41:50AM +1000
On Sun, Jul 29, 2001 at 11:41:50AM +1000, Andrew Morton wrote:
>
> Be very wary of optimising for dbench.
>
> It's a good stress tester, but I don't think it's a good indicator of how
> well an fs or the VM is performing. It does much more writing than a
> normal workload mix. It generates oceans of metadata.
People should keep in mind what dbench was originally written to do
--- to be a easy-to-run proxy for the netbench benchmark, so that
developers could have a relatively easy way to determine how
well/poorly their systems would run on netbench run without having to
set up an expensive and hard-to-maintain cluster of Windows clients in
order to do a full-blown netbench benchmark.
Most people agree that netbench is a horrible benchmark, but the
reality is that it's what a lot of the world (including folks like
Mindcraft) use it for benchmarking SMB/CIFS servers. So while we
shouldn't optimize dbench/netbench numbers at the expense of
real-world performance, we can be sure that Microsoft will be doing so
(and will no doubt call in Mindcraft or some other "independent
benchmarking/testing company" to be their shill once they've finished
with their benchmark hacking. :-)
> It would be very useful to have a standardised and very carefully
> chosen set of tests which we could use for evaluating fs and kernel
> performance. I'm not aware of anything suitable, really. It would
> have to be a whole bunch of datapoints sprinkled throughout a
> multidimesional space. That's what we do at present, but it's ad-hoc.
All the gripes about dbench/netbench aside, one good thing about them
is that they hit the filesystem with a large number of operations in
parallel, which is what a fileserver under heavy load will see.
Benchmarks like Andrew and Bonnie tend to have a much more serialized
pattern of filesystem access.
- Ted
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
next prev parent reply other threads:[~2001-07-30 3:19 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-27 21:08 2.4.8-pre1 and dbench -20% throughput Roger Larsson
2001-07-27 21:42 ` Rik van Riel
2001-07-27 22:34 ` Daniel Phillips
2001-07-27 23:43 ` Roger Larsson
2001-07-27 23:43 ` Roger Larsson
2001-07-28 1:11 ` Daniel Phillips
2001-07-28 1:11 ` Daniel Phillips
2001-07-28 3:18 ` Daniel Phillips
2001-07-28 13:40 ` Marcelo Tosatti
2001-07-28 20:13 ` Daniel Phillips
2001-07-28 20:26 ` Linus Torvalds
2001-07-29 14:10 ` Daniel Phillips
2001-07-29 14:48 ` Rik van Riel
2001-07-29 15:34 ` Daniel Phillips
2001-07-29 15:31 ` Mike Galbraith
2001-07-29 16:05 ` Linus Torvalds
2001-07-29 20:19 ` Hugh Dickins
2001-07-29 20:25 ` Rik van Riel
2001-07-29 20:44 ` Hugh Dickins
2001-07-29 21:20 ` Daniel Phillips
2001-07-29 21:51 ` Hugh Dickins
2001-07-29 23:23 ` Rik van Riel
2001-07-31 7:30 ` Kai Henningsen
2001-07-31 14:13 ` Daniel Phillips
2001-07-31 17:37 ` Jonathan Morton
2001-07-29 1:41 ` Andrew Morton
2001-07-29 14:39 ` Daniel Phillips
2001-07-30 3:19 ` Theodore Tso [this message]
2001-07-30 15:17 ` Randy.Dunlap
2001-07-30 16:41 ` Theodore Tso
2001-07-30 17:52 ` Mike Galbraith
2001-07-30 19:39 ` Zlatko Calusic
2001-07-29 17:48 ` Steven Cole
2001-07-28 0:35 ` Steven Cole
2001-07-28 2:04 ` Daniel Phillips
2001-07-30 13:15 ` Marcelo Tosatti
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=20010729231920.A10320@thunk.org \
--to=tytso@mit.edu \
--cc=akpm@zip.com.au \
--cc=elenstev@mesatop.com \
--cc=linux-mm@kvack.org \
--cc=marcelo@conectiva.com.br \
--cc=mikeg@wen-online.de \
--cc=phillips@bonn-fries.net \
--cc=riel@conectiva.com.br \
--cc=roger.larsson@skelleftea.mail.telia.com \
--cc=torvalds@transmeta.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.