Messages in this thread |  | | Date | Wed, 13 Sep 2000 18:57:21 -0300 (BRST) | From | Rik van Riel <> | Subject | Re: (reiserfs) Re: More on 2.2.18pre2aa2 |
| |
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/
|  |