public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Beau Kuiper <kuib-kl@ljbc.wa.edu.au>
To: linux-kernel@vger.kernel.org
Cc: reiserfs-list@namesys.com
Subject: [PATCH] 2.4.10 improved reiserfs a lot, but could still be better
Date: Mon, 24 Sep 2001 22:09:59 +0800	[thread overview]
Message-ID: <B0005839269@gollum.logi.net.au> (raw)

Hi all again,

I have updated my last set of patches for reiserfs to run on the 2.4.10 
kernel.

The new set of patches create a new method to do kupdated syncs. On 
filesystems that do no support this new method, the regular write_super 
method is used. Then reiserfs on kupdated super_sync, simply calls the 
flush_old_commits code with immediate mode off. 

The reiserfs improvements in 2.4.10 are great, but still not as good as 
2.2.19 was.

I have run two benchmarks on:

   the 2.4.9 kernel (plain, slow, starting point)
   the 2.4.9 kernel (with kupdated disabled, this is where we want to be)
   the 2.4.10 kernel (plain, quite fast though)
   the 2.4.10 kernel with my patches.

The benchmarks are:

   dbench 10 (done 4 times, with first result discarded)
   kernel compliation times (done twice, with first result discarded)

The first result in all benchmarks is discarded because it is used to set up 
the cache to a consistant state.

All benchmarks are run on the following machine:

Duron 700
VIA KT133 northbridge and 686A southbridge.
384meg RAM
40 gig IBM drive (7200rpm, GXP60)

The IBM drive has its internal write caching disabled (because it is damned 
good :-) ) since it hides the problems that my old drive had (I upgraded a 
few days ago)

I was going to use an old Quantum 5400rpm drive for these benchmarks but I 
blew it up ;-) (I got fire!! on one of the chips and everything, somehow 
managed to plug power cable into it backwards) Its smell is still lingering 
as I write this. Could someone with a slow 5400rpm drive do these tests and 
report back.

Anyway, enough yabbering, onto the results

---- 2.4.9 (plain)

dbench: 25.6155, 24.4236, 26.05 MB/Sec

kernel compile: 5.41.744 wall time, 4.43.880 user time, 0.16.380 sys time

---- 2.4.9 (kupdated off)

dbench: 33.763, 36.452, 32.0602 MB/Sec

kernel compile: 5.7.967 wall time, 4.44.140 user time, 0.15.380 sys time

---- 2.4.10 (plain)

dbench: 35.3584, 31.1634, 32.3602 MB/Sec

kernel compile: 5.21.458 wall time, 4.43.840 user time, 0.14.590 sys time

---- 2.4.10 (patched with attached patch)

dbench : 35.028, 33.6774, 38.2342 MB/Sec

kernel compile: 5.4.640 wall time, 4.42.950 user time, 0.15.160 sys time

Conclusions:

The 2.4.10 kernel improved reiserfs performace a lot all by itself, 
especially in dbench. In kernel compiles, however (maybe because dbench 
doesn't stress kupdated much), it still isn't as fast as my new patch.

Also, the performace problems seem to be very dependant on the hardware being 
used. 5400rpm drives get hurt a lot, while 7200 rpm drives seem to handle it 
better. Decent write caching on IDE devices (like the 2meg buffer on the IBM) 
can completely hide this issue.

Thanks to everyone who has helped me so far, and I look forward to further 
comments and assistance,
Beau Kuiper
kuib-kl@ljbc.wa.edu.au

             reply	other threads:[~2001-09-24 14:08 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-24 14:09 Beau Kuiper [this message]
2001-09-24 14:46 ` [reiserfs-list] [PATCH] 2.4.10 improved reiserfs a lot, but could still be better Chris Mason
2001-09-24 15:32 ` Matthias Andree
2001-09-24 15:45   ` Alan Cox
2001-09-24 15:47     ` Matthias Andree
2001-09-24 16:08       ` Alan Cox
2001-09-24 16:08         ` [reiserfs-list] " Chris Dukes
2001-09-24 16:54         ` Matthias Andree
2001-09-24 16:15   ` Nicholas Knight
2001-09-24 16:40     ` [reiserfs-list] " Lehmann 
2001-09-24 16:53     ` Matthias Andree
2001-09-24 16:57       ` [reiserfs-list] " Lehmann 
2001-09-25 14:04         ` bill davidsen
2001-09-25 17:39           ` bill davidsen
2001-09-24 20:05       ` Nicholas Knight
2001-09-25  0:11         ` Matthias Andree
2001-09-25  4:49           ` Nicholas Knight
2001-09-25  6:00             ` Beau Kuiper
2001-09-25  6:17               ` Nicholas Knight
2001-09-25 10:44               ` Matthias Andree
2001-09-25 11:01                 ` ben-lists
2001-09-25 10:42             ` Matthias Andree
2001-09-25 11:07               ` Nicholas Knight
2001-09-25 14:47           ` Alex Bligh - linux-kernel
2001-09-25 15:13             ` Matthias Andree
2001-09-25 15:23             ` John Alvord
2001-09-25 22:41               ` bill davidsen
2001-09-25 12:54     ` Jorge Nerín
2001-09-25 13:06       ` [reiserfs-list] " Chris Mason
2001-09-25 13:17       ` Matthias Andree
  -- strict thread matches above, loose matches on Subject: below --
2001-09-24 21:58 Dieter Nützel
2001-09-25  0:19 ` Matthias Andree

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=B0005839269@gollum.logi.net.au \
    --to=kuib-kl@ljbc.wa.edu.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiserfs-list@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox