All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Fedyk <mfedyk@matchmail.com>
To: "Jeff V. Merkey" <jmerkey@vger.timpanogas.org>
Cc: Andrew Morton <akpm@zip.com.au>,
	linux-kernel@vger.kernel.org, jmerkey@timpanogas.org
Subject: Re: Putrid Elevator Behavior 2.4.18/19
Date: Mon, 25 Mar 2002 17:42:19 -0800	[thread overview]
Message-ID: <20020326014219.GA3536@matchmail.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.
> > 
> > Jeff
> > 
> 
> 
> Andrew,
> 
> 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.
>

That's good news.

Are you still working on the A/B list patch?  I'd imagine that it could make
several problems easier to fix in the block layer.

> :-)
>

:)

  reply	other threads:[~2002-03-26  1:41 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 [this message]
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=20020326014219.GA3536@matchmail.com \
    --to=mfedyk@matchmail.com \
    --cc=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 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.