Hi,
On Tue, Sep 12, 2000 at 04:08:54PM +0200, Andrea Arcangeli wrote:
>
> >Andrea - latency is time measured and perceived. Doing it time based seems to
> >make reasonable sense. I grant you might want to play with the weighting per
>
> When you have a device that writes a request every two seconds you still
> want it not to seek all the time because this would mean to make it even
> slower. No?
Agreed. Doing latency this way scales the latency expectations with
the speed of the device --- quite fair.
However, that doesn't avoid the fact that the current scheme has
other, enormous unfairnesses in it. If you ignore time, then what
unit are you going to use to measure queue lengths?
You could use number-of-requests, but that can't distinguish between
1-block requests and 128-block requests.
You could use number-of-sectors, but that can't distinguish between
random access and sequential access.
Basically the measurements we take in the current elevator code can
result in our latency guarantees, in real time, on the same device,
varying by a factor of 100 depending on the load.
Using a time metric would help to fix this. There are other ways we
might improve things too, however. We could easily reduce the
elevator latency targets --- right down to maybe 5 or 10 --- if
we didn't count merges against the latencies. That would still give
us a weak ordering on seeks but without the penalties against
sequential accesses that we get when we turn down the latencies in the
current code.
We could even try being more advanced, and account out-of-order
non-merge queue inserts as being more costly than merges: decrement
request latencies by one on a merge, as we do now, but decrement them
by a higher number on other request inserts.
The point is that you don't actually _have_ to measure in absolute
wall-clock time, but simply ignoring the fact that some requests are
faster than others isn't a very good answer either.
Cheers,
Stephen
-
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:20 EST