In article <Pine.LNX.4.33.0108051315540.7988-100000@penguin.transmeta.com> you wrote:
> In general, I think we can get latency to acceptable values, and latency
> is the _hard_ thing. We seem to have become a lot better already, by just
> removing the artificial ll_rw_blk code.
Ok how about a scheme (in 2.5) where every request has a "priority" assigned
to it. The way I see this is:
* priority is a signed value
* negative priority means "no need to do IO yet" to allow for gathering
and grouping more requests in the request queues. It would be possible
to get most of the inactive-dirty list in this state, eg io scheduled but
not yet running
* on merging requests, the highest priority obviously becomes the overall
priority of the request
* "interactive" requests get a higher priority; this can be helped by adding
a ll_rw_block_sync function, as 99% if the ll_rw_block users ends up
waiting for io anyway
* priority needs to be "aged up" in time to take care of latency and such
If a device is truely idle (eg no io for X jiffies), it could steal negative
requests from the queue to do preemtive writes in order to prevent the
current situation of 5 seconds of no IO, and then suddenly a problem and
long-latency IO.
Also, intelligent devices such as aacraid, where the hardware controller has
the notion of priority, can be used more effectively this way. Such hardware
raid controllers also like to have deep IO queues for non-priority requests
to keep all disks in the raid array busy...
Comments ?
Greetings,
Arjan van de Ven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 07 2001 - 21:00:36 EST