Messages in this thread | | | Date | Mon, 14 Apr 2003 23:28:31 +1000 | From | Nick Piggin <> | Subject | Re: Benefits from computing physical IDE disk geometry? |
| |
Mark Hahn wrote:
>>>>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 >>>> > >but seek time is some combination of headswitch time, rotational >latency, and actual head motion. the first three are basically >not accessible in any practical way. the latter is easy, and the > Yep which is one reason why I don't think being fancy will pay off (the other reason being that even if you did know the parameters I don't think they would help a lot).
I just want to know the average seek time.
> >current approximation (seek time is a linear function of block distance) >is very reasonable. > Well, strictly, not linear. But yes it does provide a good ordering. That is besides the point though: I can decide if one request will have a shorter seek time than another just fine. I would still like to know the aproximate seek _time_ for higher level tuning stuff eg. will anticipation be worth it, and how soon should requests expire.
> > >adjusting the cost function would be interesting: I'm guessing that >handling short seeks (which are quite fast) would be more important >than adjusting for zones. given that the current queueing code >handles starvation, I wonder if we could actually permit backward >seeks of, say, 0-2 cylinders. > There is (in AS) no cost function further than comparing distance from the head. Closest forward seek wins.
If by the queueing code you mean the actual IO schedulers? Then yes, they do handle starvation, however they (AS, deadline) handle _fairness_ by not seeking backward. Well actually AS does allow a process to seek upto IIRC 256MB backward which is a couple of ext2 blockgroups while maintaining quite good fairness.
> > >>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. >> > >exactly. > >
- 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/
| |