lkml.org 
[lkml]   [2000]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 12:41    [W:0.022 / U:215.164 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site