All of lore.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <conman@kolivas.net>
To: Hans Reiser <reiser@namesys.com>, Andrew Morton <akpm@digeo.com>
Cc: linux-kernel@vger.kernel.org, Alexander Zarochentcev <zam@namesys.com>
Subject: Re: [BENCHMARK] ext3, reiser, jfs, xfs effect on contest
Date: Sat, 1 Feb 2003 09:21:59 +1100	[thread overview]
Message-ID: <200302010921.59861.conman@kolivas.net> (raw)
In-Reply-To: <3E3ACEA8.8070504@namesys.com>

On Saturday 01 Feb 2003 6:29 am, Hans Reiser wrote:
> Andrew Morton wrote:
> >Hans Reiser <reiser@namesys.com> wrote:
> >>compilation is not an effective benchmark anymore, not for Linux
> >>filesystems, they are all just too fast (or is it that the compilers are
> >>too slow?....)
> >
> >The point of this test is to measure interactions, and fairness.
> >
> >It answers the question "how much impact does heavy filesystem I/O have
> > upon other system activity?".
> >
> >The "other system activity" in this test is a kernel compile.  That is a
> >fairly reasonable metric, because it is sensitive to latencies in
> > servicing reads and it is sensitive to inappropriate page replacement
> > decisions.
> >
> >A more appropriate foreground load might be opening a word processor and
> >composing a short letter to Aunt Nellie, but that's harder to automate. 
> > We expect that reduced kernel compilation time will correlate with
> > lower-latency letter writing.
>
> I think the result of the test was that this was not a compelling reason
> for users selecting a particular one of the filesystems because they all
> did well enough at it.  Perhaps because of your code.:)
>
> However,  it is rather interesting for all the reasons you mention.
> There is indeed a tendency for benchmarks to discount the importance of
> latency, and this benchmark does not do that, which is good.  It is
> annoying to be unable to work while a big tar is running in the
> background, but few benchmarks capture that.
>
> We should test reiser4 against this next month, it would be
> interesting.  (It seems we finally fixed the Reiser4 performance problem
> that we hit in August, and now we just need to tweak the CPU usage a bit
> and we'll have something performing pretty decently in our next
> release....)

Actually the most "felt" of these loads is io_load and based on these results:
io_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2559ext3        3       109     68.8    4       10.1    1.40
2559jfs         3       138     54.3    11      13.8    1.77
2559reiser      3       98      76.5    2       9.2     1.24
2559xfs         3       124     60.5    6       8.0     1.57

I'd say barring any concern about throughput which this doesnt claim to 
measure accurately reiserfs causes the least slowdown of the system  ;-)

I do have one more load which may be useful. dbench_load continually runs 
dbench in the background. I could throw that at it also.

Ext2 was left out for clarity because it wasn't a journalling fs but it's 
results are quite different to the journalled fss.

Con

  reply	other threads:[~2003-01-31 22:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-31 13:20 [BENCHMARK] ext3, reiser, jfs, xfs effect on contest Con Kolivas
2003-01-31 13:37 ` Hans Reiser
2003-01-31 13:40   ` Con Kolivas
2003-01-31 13:56     ` Hans Reiser
2003-01-31 14:15       ` Con Kolivas
2003-01-31 15:21       ` Dave Jones
2003-01-31 16:40         ` Hans Reiser
2003-01-31 16:47           ` Dave Jones
2003-01-31 17:11             ` Hans Reiser
2003-01-31 19:04   ` Andrew Morton
2003-01-31 19:29     ` Hans Reiser
2003-01-31 22:21       ` Con Kolivas [this message]
2003-01-31 23:18         ` Con Kolivas
2003-02-01  0:19         ` David Lang
2003-01-31 14:09 ` Mike A. Harris
2003-01-31 14:18   ` Con Kolivas
2003-01-31 15:00   ` Maciej Soltysiak
2003-02-01  0:12 ` Con Kolivas

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=200302010921.59861.conman@kolivas.net \
    --to=conman@kolivas.net \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiser@namesys.com \
    --cc=zam@namesys.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.