All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: Roland Kuhn <rkuhn@e18.physik.tu-muenchen.de>
Cc: Oleg Drokin <green@namesys.com>, linux-kernel@vger.kernel.org
Subject: Re: reiserfs blocks long on getdents64() during concurrent write
Date: 05 Aug 2002 20:47:55 -0400	[thread overview]
Message-ID: <1028594875.27694.350.camel@tiny> (raw)
In-Reply-To: <Pine.LNX.4.44.0208060030150.1357-100000@pc40.e18.physik.tu-muenchen.de>

On Mon, 2002-08-05 at 18:46, Roland Kuhn wrote:
> > 
> Ahh, thanks! This sounds like a good idea to me, hopefully your patch will 
> be accepted despite the fact that Alan is busy doing other things ;-)
> 
> Coming back to the issue: applying these patches increased the throughput
> by about 20% :-) Now it takes about 100sec instead of 120sec to write a
> 2GB file. Tomorrow I will try it without the write_times part, to see how 
> much that does.

The write_times patch fixes a lot of latency problems, but all 5 of my
patches kind of build on each other to solve problems in different
workloads.

> 
> But more important: the hiccups are more seldom and sometimes shorter than 
> before. With plain 2.4.19 I would hit it about twice per minute (I have 
> not measured it), now it happens only after two minutes when writing 1M 
> chunks at 20MB/s. The longest seen so far was also about 4 seconds, 
> though.

This is harder to guess at ;-)  But I'll try 2 things I know I've fixed.

#1 I've made the metadata writeback code much more efficient, especially
for smaller transactions.  A dd to a large file won't generate lots of
log traffic, writing 700M only changes about 160 blocks in 30 seconds. 
Anyway, 03-data-logging-24 might make a big difference.

#2 During an ls, the current code ends up reading the directory more or
less one block at a time.  Try 05-search_reada-4.diff, which will read
more tree nodes at once.

If that still doesn't work, I'm porting forward some reiserfs
low-latency work that andrew morton did, we can give it a try.

-chris







  reply	other threads:[~2002-08-06  0:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-04 16:09 reiserfs blocks long on getdents64() during concurrent write Roland Kuhn
2002-08-05  5:44 ` Oleg Drokin
2002-08-05  9:22   ` Roland Kuhn
2002-08-05  9:54     ` Oleg Drokin
2002-08-05 10:51       ` Roland Kuhn
2002-08-05 11:04         ` Oleg Drokin
2002-08-05 18:19           ` Roland Kuhn
2002-08-05 18:30             ` Oleg Drokin
2002-08-05 18:54               ` Chris Mason
2002-08-05 19:48                 ` Roland Kuhn
2002-08-05 20:02                   ` Roland Kuhn
2002-08-05 22:14                     ` Chris Mason
2002-08-05 22:46                       ` Roland Kuhn
2002-08-06  0:47                         ` Chris Mason [this message]
2002-08-06 10:01                           ` Roland Kuhn
2002-08-05 19:11               ` Roland Kuhn

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=1028594875.27694.350.camel@tiny \
    --to=mason@suse.com \
    --cc=green@namesys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rkuhn@e18.physik.tu-muenchen.de \
    /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.