From: Chris Mason <mason@suse.com>
To: Beau Kuiper <kuib-kl@ljbc.wa.edu.au>, linux-kernel@vger.kernel.org
Cc: tovarlds@transmeta.com
Subject: Re: [PATCH] Significant performace improvements on reiserfs systems, kupdated bugfixes
Date: Thu, 20 Sep 2001 08:16:02 -0400 [thread overview]
Message-ID: <391950000.1000988162@tiny> (raw)
In-Reply-To: <Pine.LNX.4.30.0109201445170.13543-100000@gamma.student.ljbc>
In-Reply-To: <Pine.LNX.4.30.0109201445170.13543-100000@gamma.student.ljbc>
On Thursday, September 20, 2001 03:12:44 PM +0800 Beau Kuiper
<kuib-kl@ljbc.wa.edu.au> wrote:
> Hi,
>
> Resierfs on 2.4 has always been bog slow.
>
> I have identified kupdated as the culprit, and have 3 patches that fix the
> peformance problems I have had been suffering.
Thanks for sending these along.
>
> I would like these patches to be reviewed an put into the mainline kernel
> so that others can testthe changes.
>
> Patch 1.
>
> This patch fixes reiserfs to use the kupdated code path when told to
> resync its super block, like it did in 2.2.19. This is the culpit for bad
> reiserfs performace in 2.4. Unfortunately, this fix relies on the second
> patch to work properly.
I promised linus I would never reactivate this code, it is just too nasty
;-) The problem is that write_super doesn't know if it is called from sync
or from kupdated. The right fix is to have an extra param to write_super,
or another super_block method that gets called instead of write_super when
an immediate commit is not required.
It is possible to get almost the same behaviour as 2.2.x by changing the
metadata sync interval in bdflush to 30 seconds.
>
> Patch 2
>
> This patch implements a simple mechinism to ensure that each superblock
> only gets told to be flushed once. With reiserfs and the first patch, the
> superblock is still dirty after being told to sync (probably becasue it
> doesn't want to write out the entire journal every 5 seconds when kupdate
> calls it). This caused an infinite loop because sync_supers would
> always find the reiserfs superblock dirty when called from kupdated. I am
> not convinced that this patch is the best one for this problem
> (suggestions?)
It is ok to leave the superblock dirty, after all, since the commit wasn't
done, the super is still dirty. If the checks from reiserfs_write_super
are actually slowing things down, then it is probably best to fix the
checks.
>
> Patch 3
>
> This patch was generated as I was exploring the buffer cache, wondering
> why reiserfs was so slow on 2.4. I found that kupdated may write buffers
> that are not actually old back to disk. Eg
>
> Imagine that there are 20 dirty buffers. 16 of them are more that 30
> seconds old (and should be written back), but the other 4 are younger than
> 30 seconds. The current code would force all 20 out to disk, interrupting
> programs still using the young 4 until the disk write was complete.
>
> I know that it isn't a major problem, but I found it and I have written
> the patch for it :-)
>
> Please try out these patches and give comments about style, performace
> ect. They fixed my problems, sliced almost a minute off 2.2.19 kernel
> compile time on my duron 700 (from 4min 30sec to 3min 45sec)
Doe you have the results of the individual fixes?
thanks,
Chris
next prev parent reply other threads:[~2001-09-20 12:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-20 7:12 [PATCH] Significant performace improvements on reiserfs systems, kupdated bugfixes Beau Kuiper
2001-09-20 12:16 ` Chris Mason [this message]
2001-09-20 15:20 ` Beau Kuiper
2001-09-20 16:15 ` Andreas Dilger
2001-09-20 16:22 ` Beau Kuiper
2001-09-21 20:12 ` Lehmann
2001-09-21 20:57 ` Rik van Riel
2001-09-21 22:50 ` Lehmann
2001-09-21 13:26 ` Matthias Andree
2001-09-22 18:38 ` Beau Kuiper
2001-09-22 19:32 ` Matthias Andree
2001-09-23 15:24 ` Chris Mason
2001-09-24 14:37 ` Stephen C. Tweedie
-- strict thread matches above, loose matches on Subject: below --
2001-09-20 17:23 Chris Mason
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=391950000.1000988162@tiny \
--to=mason@suse.com \
--cc=kuib-kl@ljbc.wa.edu.au \
--cc=linux-kernel@vger.kernel.org \
--cc=tovarlds@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox