> 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. If you
could magically predict the seek time between any two accesses, then you
could sort your queue optimally. What would be able to do that? A neural
net? :) What would be able to do that without a lot of training time?
Personally, I've been excited about AS, and I would hate to see it not get
in.
-
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/