public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Marc-Christian Petersen <m.c.p@wolk-project.de>
Cc: linux-kernel@vger.kernel.org, Con Kolivas <conman@kolivas.net>
Subject: Re: 2.[45] fixes for design locking bug in wait_on_page/wait_on_buffer/get_request_wait
Date: Sat, 16 Nov 2002 18:32:24 +0100	[thread overview]
Message-ID: <20021116173224.GG31697@dualathlon.random> (raw)
In-Reply-To: <200211161810.23039.m.c.p@wolk-project.de>

On Sat, Nov 16, 2002 at 06:23:26PM +0100, Marc-Christian Petersen wrote:
> On Saturday 16 November 2002 17:59, Andrea Arcangeli wrote:
> 
> Hi Andrea,
> 
> > Your pausing problem have little to do with the pausing fix, the problem
> > for you is the read latency, you're not triggering the race condition
> > fixed by the pausing fix so it can't make differences. One of the
> > foundamental obstacles to the read latency is the size of the I/O queue,
> > factor that is workarounded by the read-latency patch that basically
> > bypasses the size of the queue hiding the problem and in turn can't fix
> > the write latency with O_SYNC and the read latency during true read aio
> > etc...
> ok, after some further tests, I think this is _somewhat_ FS dependent. I tried 
> this with ext2, ext3 (no difference there) and also with ReiserFS and what 
> must I say, those "Pausings" caused be the write latency doing it with 
> ReiserFS are alot less than with ext2|ext3 but are still occuring.
> 
> There must went in something bullshitty into 2.4.19/2.4.20 that causes those 
> ugly things because 2.4.18 does not have that problem. This is still why I 
> don't use any kernels >2.4.18.
> 
> After changing elevator things like this:
> 
> root@codeman:[/] # elvtune /dev/hda
> 
> /dev/hda elevator ID            0
>         read_latency:           2048
>         write_latency:          1024
>         max_bomb_segments:      0
> 
> those "pausings" are less worse than before but are still there.
> NOTE: Write latency is lower than read latency (it's not a typo :)

you may want to try with this setting that helps with very slow devices:

	echo 2 500 0 0 500 3000 3 1 0 > /proc/sys/vm/bdflush

or also with my current default tuned for high performance:

	echo 50 500 0 0 500 3000 60 20 > /proc/sys/vm/bdflush

you may have too many dirty buffers around and you end running at disk
speed at every memory allocation, the first setting will decrease the
amount of dirty buffers dramatically, if you still have significant
slowdown with the first setting above, it's most probably only the usual
elevator issue.

Andrea

  reply	other threads:[~2002-11-16 17:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-16 16:24 2.[45] fixes for design locking bug in wait_on_page/wait_on_buffer/get_request_wait Marc-Christian Petersen
2002-11-16 16:59 ` Andrea Arcangeli
2002-11-16 17:23   ` Marc-Christian Petersen
2002-11-16 17:32     ` Andrea Arcangeli [this message]
2002-11-16 17:43       ` Marc-Christian Petersen
2002-11-16 18:46         ` Andrea Arcangeli
  -- strict thread matches above, loose matches on Subject: below --
2002-11-16 18:58 Marc-Christian Petersen
2002-11-16 21:55 ` Marc-Christian Petersen
2002-11-17 17:37   ` Marc-Christian Petersen
2002-11-17 19:19     ` Folkert van Heusden
2002-11-12  3:57 Andrea Arcangeli
2002-11-12  8:50 ` Andrew Morton
2002-11-12 18:15   ` Andrea Arcangeli
2002-11-12 19:46     ` Andrew Morton
2002-11-13  0:33       ` Andrea Arcangeli
2002-11-13  1:01         ` Andrew Morton

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=20021116173224.GG31697@dualathlon.random \
    --to=andrea@suse.de \
    --cc=conman@kolivas.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.c.p@wolk-project.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox