Timothy Miller wrote:
>From: "Nick Piggin" <piggin@cyberone.com.au>
>
>
>>The benefit I see is knowing the seek time itself (not geometry), which
>>can be used to tune the IO scheduler. This is something that I'll
>>probably need to do (in kernel) in order to get my IO scheduler in 2.6,
>>as it probably (not tested yet) has bad failure cases on high seek time
>>devices like CDROMs.
>>
>
>Well, that IS the heart of the matter, really. Detecting geometry was only
>a means to the end of predicting seek time and rotational latency.
>
OK yeah. I thought you had more exotic techniques in mind
like rotational latency optimisation which require actual geometry
> If you
>could magically predict the seek time between any two accesses, then you
>could sort your queue optimally.
>
Well using the assumption that |head sector - target sector| gives
an ordering correstponding to seek time, we do sort the queue optimally.
I personally feel that being trickier than that is too much complexity.
>What would be able to do that? A neural
>net? :) What would be able to do that without a lot of training time?
>
I think just some averages, maybe histograms. Not quite sure exactly
how I'll need to do it. I probably want each IO submitting process'
average seek time, and the average seek time when changing from one
process to another. Nothing too fancy.
>
>
>Personally, I've been excited about AS, and I would hate to see it not get
>in.
>
It is getting there. It definitely does some things much better than
deadline, although in other areas it is not so good.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Apr 15 2003 - 22:00:29 EST