On Wed, Sep 13, 2000 at 08:08:51PM -0400, Giuliano Pochini wrote:
> > And if so, in what unit do you want to measure
> > latency if it isn't time?
>
> I had a look at the new elevator. I hope I'm not wrong here... Requests
> are added to the queue scanning it starting from the tail. When the
> new request if found in-order with ad existing one, it's inserted int
> the queue, unless it finds an existing request out of latency units. In
> that case the new rq is added before it (so it will be serviced after).
If I understand this correctly, that means once the queue is too long
(latency wise) the elevator will stop working completely, because all
requests will be served in the order they come in. right?
If multiple queues are used, so performance is OK even when the first
queue is full (too old), the discussion about how to tell if the queue
is too old or not (by time or requests) becomes less important. After
all, there is no reason not to start a new queue pretty often, even on a
fast device.
The correct behavoir would be to reorderder the new requests
individually even if the queue is alreaddy too long. In other words -
multiple queues.
> not work this way. The main problem is that it doesn't minimize head
> movement. For example, when comes a request for a sector at the
> beginning of the disk it goes to the beginning of the queue (it's
> ordered) so it will be serviced before other rqs (it picks up rqs from
> the head). This way the higher is the block number, more likely that
> rq will wait a lot.
If a new request is made for a sector before the current sector (the
sector of the last request to be served), the new request should be
added to the second queue even if the first one is not too old.
-- Ragnar Kjørstad - 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