public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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