On Fri, Apr 6, 2012 at 2:32 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Anyway, this works for me on x86 (you need current tip-of-git for the
> <asm/word-at-a-time.h> thing) and is quite noticeable in profiles
> (well, if you have loads that do a lot of pathname lookups: I use a
> microbenchmarks that does ten million lookups of a filename with
> multiple components, but I also do "make -j" profiles of a fully build
> tree).
Some actual numbers: my microbenchmark used to take just over 9s
(best-of-six:9.053s) back before the dcache lookup optimizations
With some of the __d_lookup_rcu cleanups, and doing dentry_cmp() a
word at a time, that best-of-six dropped to 8.504s, and then
eventually with the full word-wide hashing it dropped to 8.013s. Some
more optimization got it consistently into the mid-sevens, which is
roughly where 3.4-rc1 was.
Today, my "best-of-six" numbers are 6.301s for that same binary, on
the same machine. Now, the numbers aren't hugely stable, and I didn't
do the same pre-population of the dcache that I did with the earlier
numbers, so it's not entirely comparable. But it's basically
approaching almost 30% better than the original code.
Admittedly just on a silly micro-benchmark, but still: all that
benchmark does is just "stat()" the same path over and over - which is
not a totally unrealistic thing to do. The "same path" means that it
doesn't show the cache effects as much (and the profiles are much
"sharper"). And while the "make -j" thing clearly shows different
profiles, the top five kernel functions have actually been pretty
consistent between the two cases, even if the details change.
Note: extra good numbers are with all my (uncommitted) selinux fixes
too, and there is a fair amounf of fluctuation in the numbers (lots
and lots of cache effects), but the strncpy change did make a
noticeable difference. Earlier today, I had a hard time getting the
number under 7s. Getting to 6.3 was partly strncpy, but about half of
it was my very experimental selinux stuff. Some of which might never
end up being committed, who knows..
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
