Re: stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest]

[Andrea Arcangeli]

On Mon, Feb 10, 2003 at 10:45:59PM +1100, Nick Piggin wrote:
> perspective it does nullify the need for readahead (though
> it is obivously still needed for other reasons).

I'm guessing that physically it may be needed from a head prospective
too, I doubt it only has to do with the in-core overhead.  Seeing it all
before reaching the seek point might allow the disk to do smarter things
and to keep the head at the right place for longer, dunno.  Anyways,
whatever is the reason it doesn't make much difference from our point of
view ;), but I don't expect this hardware behaviour changing in future
high end storage.

NOTE: just to be sure, I'm not at all against anticpiatory scheduling,
it's clearly a very good feature to have (still I would like an option
to disable it especially in heavy async environments like databases,
where lots of writes are sync too) but it should be probably be enabled
by default, especially for the metadata reads that have to be
synchronous by design.

Infact I wonder that it may be interesting to also make it optionally
controlled from a fs hint (of course we don't pretend all fs to provide
the hint), so that you stall I/O writes only when you know for sure
you're going to submit another read in a few usec, just the time to
parse the last metadata you read. Still a timeout would be needed for
scheduling against RT etc..., but it could be a much more relaxed
timeout with this option enabled, so it would need less accurate
timings, and it would be less dependent on hardware, and it would
be less prone to generate false positive stalls. The downside is having
to add the hints.

Andrea