Re: RFC on io-stalls patch

[Jens Axboe]

On Mon, Jul 14 2003, Chris Mason wrote:
> On Mon, 2003-07-14 at 16:24, Andrea Arcangeli wrote:
> 
> > 
> > this isn't what we had in pre4, this is more equivalent to an hack in
> > pre4 where the requests aren't distributed anymore 50/50 but 10/90. Of
> > course an I/O queue filled mostly by parallel sync reads, will make the
> > writer go slower since it will very rarely find the queue not oversized
> > in presence of a flood of readers. So the writer won't be able to make
> > progress.
> > 
> > This is a "stop the writers and give unlimited requests to the reader"
> > hack, not a "reserve some request for the reader", of course then the
> > reader is faster. of course then, contest shows huge improvements for
> > the read loads.
> 
> Which is why it's a good place to start.  If we didn't see huge
> improvements here, there's no use in experimenting with this tactic
> further.

Exactly. The path I'm looking for is something ala 'at least allow one
read in, even if writes have oversized the queue'.

> > But contest only benchmarks the reader, it has no clue how fast the
> > writer is AFIK. I would love to hear the bandwidth the writer is writing
> > into the xtar_load. Maybe it's shown in some of the Loads/LCPU or
> > something, but I don't know the semantics of those fields and I only
> > look at time and ratio which I understand. so if any contest expert can
> > enaborate if the xtar_load bandwidth is taken into consideration
> > somewhere I would love to hear.
> 
> I had a much longer reply at first as well, but this is only day 1 of
> Jens' benchmark, and he had plans to test other workloads.  I'd like to
> give him the chance to do that work before we think about merging the
> patch.  It's a good starting point for the question "can we do better
> for reads?" (clearly the answer is yes).

Thanks Chris, this is exactly the point. BTW, I'd be glad to take hints
on other interesting work loads.

-- 
Jens Axboe