[lkml]   [1998]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Speeding up FAT operations
    On Wed, 16 Sep 1998, Andy Carlson wrote:
    > Have you been able to quantify your speedup in any way? I would be
    > interested in seeing that.

    Well, there's reasons that isn't practical, for example I'm currently
    using a non-standard compiler, so anybody else would get easily widely
    differing results. And given I have a Pentium II, odds are I/O is taking
    much more time than any calculations. And then there's the question what
    to measure? As if that wasn't complex enough, the slightest change in one
    part of the code may throw code and data alignment, optimization etc. off
    in far-away places making analyzing the results rather complex.

    Now, that being said... Let's take the "ls -lR torture-test". Even if you
    aren't running an FTP-server with need to generate directory-listings,
    odds are you spend much of your day browsing thru directory listings, so
    this isn't so far removed from reality. Honestly said, I didn't expect
    the results to be measurable, but they turned up to be quite so that I
    can say on my machine this drops total kernel-space CPU usage by a round
    5% during that.

    The reason it's so "low" is because in my setup fat_readdirx() is
    currently taking about 1/3rd of all processing power. This is a function
    for handling vfat extended filenames, and is another CPU-sucker I've
    tried somewhat-succesfully to optimize in the past. If this function
    wasn't involved, we'd be talking about almost 10% improvement on this
    patch. So if processing VFAT long filenames isn't involved, the gain may
    be even bigger.

    Finally, it would be nice to be able to give specific function
    effectiveness data. Unfortunately, if I tried to do that, I'd probably be
    lying, since the results on function-level are rather unusable. While the
    fat_smap() function I originally set out to optimize ended up dropping to
    less to half of the original load, fat_get_entry() jumped from almost nil
    load up to higher than was saved in fat_smap(). Conversely,
    fat_date_unix2dos() with equal load value simply disappeared off the
    chart. That's what I mean by optimization smudging the results ;)

    On the other hand, fat_get_entry() is still bothering me somewhat, I
    don't outright see why it should skyrocket on the chart like that, as it
    doesn't seem to have eaten any functions called from it, so I will be
    looking into that effect still.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.030 / U:0.932 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site