Actually, a nul-termination doesn't matter in the extension bit, as this
will just lead to few more nulls at the end of the filename, which get
skipped. I'm not sure if it'd make difference with long filenames, but
somehow I suspect there aren't many MS-DOS 1.xx VFAT-setups out there...
Anyway, there's another "problem" now, altough I've rewritten the actual
copy-over code in fat_readdirx() about as fast as it goes, the problem is
that it seems to change the code placement and optimizations in subtle
ways causing the rest of the function, unchanged, get dirt-poor
performance at least on -O2.
The whole fat_readdirx() function is actually an optimizers nightmare,
consisting of over 200 lines of deeply nested code. I've tried breakign it
up to parts a few times, without success, as the different parts are
dependent on so much state-information. Perhaps if I manage to optimize
the rest of the code, too, at least that will change the code arrangement
and possible optimization results.
Ofcourse, there's a philosophical question, if you write bit of source as
fast as it can go, and then the compiler/optimizer messes it up making it
slower, is it still better? Oh well. The bit-shift part of the patch does
speed things up currently (On ALPHA it may not, I'm told, but how many
people use *FAT on ALPHA?) but the changes to fs/fat/dir.c lead to slower
overall performance, 'though the optimized part flies.
-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/