Re: (reiserfs) Re: More on 2.2.18pre2aa2

From: Rik van Riel (riel@conectiva.com.br)
Date: Wed Sep 13 2000 - 16:57:21 EST


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