On Wed, 13 Sep 2000, Ragnar Kjørstad wrote:
> On Wed, Sep 13, 2000 at 11:22:16AM -0400, Michael T. Babcock wrote:
> > If I may ask a potentially stupid question, how can request latency be
> > anything but a factor of time? Latency is how /long/ you (or the computer)
> > /waits/ for something. That defines it as a function of time.
>
> Latency is of course a factor of time, but the point is that the
> acceptable latency differs from device to device. For a slower device
> longer latency must be acceptable, and if the relationship is linear,
> then using number of requests may be a simpler and better way of doing
> it.
>
> Another potentially stupid question:
> When the queue gets too long/old, new requests should be put in
> a new queue to avoid starvation for the ones in the current
> queue, right?
Indeed. That would solve the problem...
> So if this is done by time, how do you know when the oldest
> request get too old? You would need to index the requests both
> by sector and time, and thus performance overhead, right?
> If you, however have a simple rule that max 100 requests should
> be put in each queue, it's easy to know when to start a new one.
The idea Jeff Merkey gave us is even simpler and should work
ok every time. I think I'll implement it RSN and try if it
works ok for Linux.
(maybe with the twist that we /do/ allow merges on the queue
that's being processed by the disk, but no insertions of new
requests)
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:22 EST