On Tue, Oct 17, 2000 at 01:15:26AM -0700, Andre Hedrick wrote:
> On Tue, 17 Oct 2000, Vojtech Pavlik wrote:
>
> > > Now we can profile drives to super-charge the elevator!!
> >
> > I doubt this will ever happen. We'll see IDE drives reorder the
> > requests inside their caches sooner. The elevator will always be more
> > important to get right in terms of fairness to processes than bare
> > throughput.
>
> You do not understand the nature of what the test can generate.
> We can decode the sweep pattern now.
>
> Instead of 0->End of drive.
>
> PlatterOD->PlatterID top
> PlatterOD->PlatterID bottom.
>
> This will get us zone-profiles an determine where the sweet spots are on
> a given disk are and make a record. We whould reload the profile of the
> drive at INIT.
>
> Will explain more later, I have my two-year old in my lap asleep.
Well, I know quite well what this can bring us - with precise profiling
we could see the exact geometry of the drive, so that for example the
elevator algorithm could optimize even for going backwards, etc. Also I
know some drives (multimedia models) don't have the mapping linear, but
instead for constant throughput rate combine both inner and outer
regions all over the logical space.
However I don't believe this can bring us significant performance
enhancements and it will make the elevator algorithm even more complex
than it is now. For the OS it's more important the fairness of disk i/o
scheduling for example is much much more important than the perfect
ordering (in relation to what the drive would like to see) of the
accesses.
I've tried this some years ago on DOS with an old OMTI drive (where the
geometry was known), and optimizing the accesses two way instead of
doing a perfect one way elevator was gaining less than 1% in speed and
made the code much more complex.
It's a very interesting (and cute) idea, though. By no means think that
I'm trying to stop you from implementing that - go ahead and if you
succeed, then great! I'm just telling you that in my opinion there is
little to win and the chances are low, too. (And that there possibly are
a lot of other things in Linux IDE that need enhancing ...)
Anyway, I still think you'll have trouble with the granularity of your
analysis. Can you switch off the on-disk cache (which is quite large on
modern drives?) If not, then you won't see tricks the drive does on
blocks less than drive cachesize ...
-- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:11 EST