From: Andrew Morton <akpm@zip.com.au>
To: "Jeff V. Merkey" <jmerkey@vger.timpanogas.org>
Cc: linux-kernel@vger.kernel.org, jmerkey@timpanogas.org
Subject: Re: Putrid Elevator Behavior 2.4.18/19
Date: Wed, 20 Mar 2002 17:22:18 -0800 [thread overview]
Message-ID: <3C9935CA.38E6F56F@zip.com.au> (raw)
In-Reply-To: <20020320120455.A19074@vger.timpanogas.org> <20020320220241.GC29857@matchmail.com> <20020320152008.A19978@vger.timpanogas.org> <20020320152504.B19978@vger.timpanogas.org>
"Jeff V. Merkey" wrote:
>
> ...
> > I will comply. I tested with pre-3 patches and still saw this problem??
> > Let me go and check the patches I applied to verify, I may not have
> > applied the correct patch.
> >
> > Jeff
>
> I verified we were using a stock 2.4.18 kernel on the specific system
> without the pre-3 patches installed. We have been testing with the
> latest patches but not on this system. We will apply and retest and
> I will verify.
>
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'?
-
next prev parent reply other threads:[~2002-03-21 1:24 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 [this message]
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
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=3C9935CA.38E6F56F@zip.com.au \
--to=akpm@zip.com.au \
--cc=jmerkey@timpanogas.org \
--cc=jmerkey@vger.timpanogas.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox