Messages in this thread | | | Date | Mon, 14 Apr 2003 13:52:45 +1000 | From | Nick Piggin <> | Subject | Re: Benefits from computing physical IDE disk geometry? |
| |
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/
| |