Re: Name hashing function causing a perf regression

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sat, Sep 13, 2014 at 11:58 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So if this all helps you guys, and after sufficient testing, just the
> current top commit should be self-sufficient (with two other commits
> before *if* that multiply-vs-shift makes a difference)
>
>     99d263d4c5b2 (HEAD, master) vfs: fix bad hashing of dentries
>
> and if it *doesn't* help, and you still see problems, please holler.

Btw, please if at all possible, give the 3.17-rc5 release a test on
the load that you saw problems with.

Because of the whole dentry hashing issue, I took another look at name
lookup performance, and found a few more problems in this area.

The biggest problem only affected the fairly unusual case of a
directory that was mounted differently in different namespaces, and it
may well be that you don't actually have that situation at all. I
found it almost by mistake when checking performance consistency and
noticing that my "/tmp" directory lookups were much slower than
everything else. The pathname lookup incorrectly dropped out of RCU
mode for that case due to two independent bugs (one hit normal lookups
of such directories, the other hit just the ".." case).

I also hit a small CPU pipeline hickup in link_path_walk() that is
probably specific to just the store buffer forwarding of x86-64, but
could possibly hit other 64-bit cases too. I doubt it's noticeable for
your case, but it showed up pretty clearly in the profiles when I was
checking that everything looked ok.

All of them should be fixed in the -rc5 I just pushed out. At least I

I do have another case I'm not entirely happy about - our negative
lookups (ie looking up a pathname that doesn't exist) hit in the
dcache for real filesystems and perform really well, but they suck for
tmpfs. Al, we turn off negative dentry caches for tmpfs because
simple_dentry_operations uses

        .d_delete = always_delete_dentry,

Do we care? It's noticeable in benchmarks: it's almost an order of
magnitude difference when looking up non-existent files. I can look up
a non-existent file 23M times per second on ext4, but only 3.3M on
/tmp.

Anyway, I'm not sure FB does a lot of lookups of nonexistent files,
but there are some loads that really do that a lot.  And we're in the
odd situation that it's actually *much* faster on a real filesystem
than it is on a RAM filesystem like /tmp.

                   Linus