Re: Benefits from computing physical IDE disk geometry?

[Nick Piggin]

Timothy Miller wrote:

>From: "Nick Piggin" <[e-mail]>
>
>
>>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.