From: David Rees <dbr@greenhydrant.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Putrid Elevator Behavior 2.4.18/19
Date: Mon, 25 Mar 2002 17:45:55 -0800 [thread overview]
Message-ID: <20020325174555.A3252@greenhydrant.com> (raw)
In-Reply-To: <20020320120455.A19074@vger.timpanogas.org> <20020320220241.GC29857@matchmail.com> <20020320152008.A19978@vger.timpanogas.org> <20020320152504.B19978@vger.timpanogas.org> <3C9935CA.38E6F56F@zip.com.au> <20020320234552.A21740@vger.timpanogas.org> <20020325181645.A17171@vger.timpanogas.org>
On Mon, Mar 25, 2002 at 06:16:45PM -0700, Jeff V. Merkey wrote:
> > > The elevator starvation change went into 2.4.19-pre1 I think.
> > > It shouldn't affect the problem which you've described - that
> > > change improved the situation where tasks were sleeping for
> > > long periods when they want to insert new requests. But the
> > > problem which you're observing appears to affect already-inserted
> > > requests.
> > >
> > > "Several minutes" is downright odd. From your description
> > > it seems that all the requests are writes, but some of the
> > > writes (at a remote end of the disk) are being bypassed far
> > > too many times.
> > >
> > > The bypass count _is_ tunable. Although it sounds like the logic
> > > has come unstuck in some manner, it would be interesting if
> > > changing the elevator latency parameters for that queue affected
> > > the situation.
> > >
> > > Have you experimented with `elvtune -r NNN /dev/foo' and
> > > `elvtune -w NNN /dev/foo'?
> >
> > No, but I will test this tonight. I am in tonight working on
> > this problem until I run it down.
>
> I have been running a test run against 2.4.19-pre4 (and later) for
> over a week non-stop and the elevator problem appears to have been
> corrected by this fix. I will update further if the problem
> resurfaces.
Jeff,
Did upgrading to 2.4.19-pre4 by itself fix your problems, or did you need to
tweak with elvtune as well? If so, what values did you find produced
optimal results?
-Dave
next prev parent reply other threads:[~2002-03-26 1:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-20 19:04 Putrid Elevator Behavior 2.4.18/19 Jeff V. Merkey
2002-03-20 22:02 ` Mike Fedyk
2002-03-20 22:20 ` Jeff V. Merkey
2002-03-20 22:25 ` Jeff V. Merkey
2002-03-21 1:22 ` Andrew Morton
2002-03-21 6:45 ` Jeff V. Merkey
2002-03-26 1:16 ` Jeff V. Merkey
2002-03-26 1:42 ` Mike Fedyk
2002-03-26 17:03 ` Jeff V. Merkey
2002-03-27 7:03 ` Jens Axboe
2002-03-27 23:20 ` Jeff V. Merkey
2002-03-26 1:45 ` David Rees [this message]
2002-03-26 1:57 ` Mike Fedyk
2002-03-26 17:00 ` Jeff V. Merkey
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=20020325174555.A3252@greenhydrant.com \
--to=dbr@greenhydrant.com \
--cc=linux-kernel@vger.kernel.org \
/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.