Messages in this thread |  | | Date | Tue, 17 Oct 2000 11:23:30 +0200 | From | Vojtech Pavlik <> | Subject | Re: New Benchmark tools, lookie looky........ |
| |
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/
|  |