> >>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
current approximation (seek time is a linear function of block distance)
is very reasonable.
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.
> 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/
This archive was generated by hypermail 2b29 : Tue Apr 15 2003 - 22:00:29 EST