RE: [PATCH] io stalls

[Chris Mason <mason@suse.com>]

On Mon, 2003-06-09 at 21:48, Robert White wrote:
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Nick Piggin
> 
> > Chris Mason wrote:
> 
> > >The major difference from Nick's patch is that once the queue is marked
> > >full, I don't clear the full flag until the wait queue is empty.  This
> > >means new io can't steal available requests until every existing waiter
> > >has been granted a request.
> 
> > Yes, this is probably a good idea.
> 
> 
> Err... wouldn't this subvert the spirit, if not the warrant, of real time
> scheduling and time-critical applications?
> 

[ lots of interesting points ]

Heh, I didn't really make my goals for the patch clear.  They go:

1) quantify the stalls people are seeing with real numbers so we can
point at a section of code causing bad performance.

2) Provide a somewhat obvious patch that makes the current
__get_request_wait call significantly more fair, in hopes of either
blaming it for the stalls or removing it from the list of candidates

3) fix the stalls

Most of your suggestions are 2.5 discussion material, where real
experimental work is going on.  The 2.4 io request wait queue isn't
working on priorities, the current one tries to be fair to everyone and
provide good throughput to everyone at the same time.  It's failing on
at least one of those, and until we can fix that I don't even want to
think about more complex issues.

Current users of the vanilla 2.4 tree will hopefully benefit from a
lower latency io request wait queue. The next best thing to real time is
a consistently small wait, which is what my patch is trying for.

-chris