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.
-Donwulff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/