From: Alex Zarochentsev <zam@namesys.com>
To: Jon Burgess <lkml@jburgess.uklinux.net>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: ext2/3 performance regression in 2.6 vs 2.4 for small interleaved writes
Date: Mon, 16 Feb 2004 20:51:27 +0300 [thread overview]
Message-ID: <20040216175127.GJ1298@backtop.namesys.com> (raw)
In-Reply-To: <402BE01E.2010506@jburgess.uklinux.net>
On Thu, Feb 12, 2004 at 08:20:46PM +0000, Jon Burgess wrote:
> Andrew Morton wrote:
>
> >I don't know why the single-stream case would be slower, but the
> >two-stream
> >
> >case is probably due to writeback changes interacting with a weakness in
> >the block allocator. 10 megs/sec is pretty awful either way.
> >
> >
> >
> 10MB/s is just because I did the test on an old machine, it maxes out at
> 15MB/s with "hdparm -t".
> I didn't want to do it on my main PC because I using it to record a TV
> program at the time :-)
>
> >Either way, you have intermingled blocks in the files.
> >
> >
> Yes the blocks are intermingled. Thanks for the explanation of the
> 2.4/2.6 difference.
>
> >Reads will be slower too - you will probably find that reading back a file
> >
> >
> Yes reads are 50% for 2 streams, 25% for 4 etc. 2.4 and 2.6 perform the
> same.
> I did a debugfs "stat" and it clearly shows the fragmented file blocks.
>
> >You can probably address it quite well within the
> >application itself by buffering up a good amount of data for each write()
> >call. Maybe a megabyte.
> >
> >
> Writes in the 256kB - 1MB region do avoid the problem. Unfortunately the
> way the application is written it makes this tricky to do. It wants to
> write out the data in one frame at a time, typically 10 - 50kB.
>
> >XFS will do well at this.
> >
> >
> Yes, both XFS and JFS perform much better. Here is a summary of some
> tests done on 2.6, these were done on a faster machine / disk
> combination. This was the original test program which also measured the
> read speeds, you can get this from http://www.jburgess.uklinux.net/slow.c
>
> The ext2 result is a bit slow, but ext3 is really bad.
>
> Num streams |1 1 |2 2
> Filesystem |Write Read |Write Read
> --------------|----------------|--------------
> Ext2 |27.7 29.17 | 5.89 14.43
> ext3-ordered |25.73 29.21 | 0.48 1.1
> Reiserfs |25.31 26.25 | 7.47 13.55
> JFS |26.27 26.95 |26.92 28.5
> XFS |27.51 26.00 |27.35 27.42
I ran slow.c on Reiser4, it is different hardware, ext2 results are for
comparing:
server config:
2xXeon, hyperthreading, 256 MB RAM
Linux-2.6.2
Test:
/tests/slow foo 1024
it writes 1GB to one or two files.
Results:
---------+------------+-----------+-----------+-----------+
| 1 stream | 2 streams |
---------+------------+-----------+-----------+-----------+
| WRITE | READ | WRITE | READ |
---------+------------+-----------+-----------+-----------+
REISER4 | 33.67 Mb/s | 40.97Mb/s | 30.78Mb/s | 38.37Mb/s |
---------+------------+-----------+-----------+-----------+
EXT2 | 33.32Mb/s | 40.82Mb/s | 9.45Mb/s | 20.39Mb/s |
---------+------------+-----------+-----------+-----------+
The fs with delayed block allocation (Reiser4, XFS, seems JFS too) look much
better.
--
Alex.
next prev parent reply other threads:[~2004-02-16 17:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-11 19:04 ext2/3 performance regression in 2.6 vs 2.4 for small interleaved writes Jon Burgess
2004-02-11 20:28 ` Rik van Riel
2004-02-11 21:02 ` Michael Frank
2004-02-11 21:18 ` Diego Calleja
2004-02-12 2:00 ` Dave Olien
2004-02-12 2:23 ` Andrea Arcangeli
2004-02-12 9:42 ` ext2/3 performance regression in 2.6 vs 2.4 for small interl Giuliano Pochini
2004-02-12 10:15 ` John Bradford
2004-02-12 10:27 ` Nick Piggin
2004-02-12 17:05 ` Michael Frank
2004-02-12 17:18 ` Valdis.Kletnieks
2004-02-12 20:55 ` Helge Hafting
2004-02-13 1:57 ` Jamie Lokier
2004-02-13 2:05 ` Nick Piggin
2004-02-12 14:59 ` Andrea Arcangeli
2004-02-13 12:15 ` ext2/3 performance regression in 2.6 vs 2.4 for small interleaved writes Jon Burgess
2004-02-12 10:40 ` Jon Burgess
2004-02-12 20:17 ` Hans Reiser
2004-02-12 9:56 ` Andrew Morton
2004-02-12 20:20 ` Jon Burgess
2004-02-13 8:28 ` Juan Piernas Canovas
2004-02-16 17:51 ` Alex Zarochentsev [this message]
2004-02-16 20:03 ` Jon Burgess
2004-02-13 12:35 ` Jon Burgess
2004-02-14 15:00 ` Jon Burgess
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=20040216175127.GJ1298@backtop.namesys.com \
--to=zam@namesys.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@jburgess.uklinux.net \
/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