> > Going in function of time is obviously wrong. A blockdevice can
> > write 1 request every two seconds or 1 request every msecond.
> > You can't assume anything in function of time _unless_ you have
> > per harddisk timing informations into the kernel.
>
> Uhmmm, isn't the elevator about request /latency/ ?
>
> 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).
After it have inserted the request it walks back and decrease all
latency counters.
So, the "unit" to measure latency is "number of requests". New requests
are not allowed to go before an existing one more than N times.
It's a good way to avoid stalls, but IMHO I thing the elevator should
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.
Again... If I understood correctly how the elevator works.
Bye.
-
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:21 EST