On Thu, Aug 11, 2022 at 08:58:54PM -0700, Linus Torvalds wrote: > On Thu, Aug 11, 2022 at 3:43 PM Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > Oh, sadly, clang does much worse here. > > > > Gcc ends up being able to not have a stack frame at all for > > __d_lookup_rcu() once that DCACHE_OP_COMPARE case has been moved out. > > The gcc code really looks very nice. > > > > Clang, not so much, and it still has spills and reloads. > > I ended up looking at the clang code generation more than I probably > should have, because I found it so odd. > > Our code is literally written to not need that many values, and it > should be easy to keep everything in registers. > > It turns out that clang is trying much too hard to be clever in > dentry_string_cmp(). The code is literally written so that we keep the > count of remaining characters in 'tcount', and then at the end we can > generate a 'mask' from that to ignore the parts of the pathname that > are beyond the size. [snip] There's a cheap way to reduce the register pressure: seq = raw_seqcount_begin(&dentry->d_seq); if (dentry->d_parent != parent) continue; if (d_unhashed(dentry)) continue; if (dentry->d_name.hash_len != hashlen) continue; if (dentry_cmp(dentry, str, hashlen_len(hashlen)) != 0) continue; *seqp = seq; could move the last store to before dentry_cmp(). Sure, we might get some extra stores out of that. Into a hot cacheline, and if we really hit many of those extra stores, we already have a problem - a lot of collisions both in ->d_parent and ->d_name.hash_len. If that happens, the cost of those extra stores is going to be trivial noise. >From correctness POV that should be fine; callers of __d_lookup_rcu() getting NULL either entirely ignore *seqp (d_alloc_parallel()) or proceed to wipe it out (lookup_fast(), by calling try_to_unlazy()). Comments?