Re: [linux-next:master] [lockref] d042dae6ad: unixbench.throughput -33.7% regression

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

On Tue, 2 Jul 2024 at 05:10, Mateusz Guzik <mjguzik@gmail.com> wrote:
>
> Well there is also the option of going full RCU in the fast path, which
> I mentioned last time around lockref.
>
> This would be applicable at least for stat, fstatx, readlink and access
> syscalls.

Yes. That would be the optimal thing - have some "don't take a lockref
on the last component at all, because we will finish the use of it
under RCU".

I looked at that some time ago, and it didn't look _horrendous_ from a
conceptual standpoint, but the details just got to be nasty.

What I wanted to do was to hook into the "we're still in RCU mode"
with a callback that stat could set.

And we'd call it at complete_walk() -> try_to_unlazy() ->
legitimize_path() time just before we do that lockref_get_not_dead()
thing.

So then the path walkers that are ok with RCU state (ie mostly just
'stat()' and friends) could set that callback, and get a callback
while the path walk is still in RCU mode, and could fill in the stat
data then and say "I'm done" and we'd never actually finalize the path
at all, and never do the final lockref_get_not_dead().

Sounds simple in theory. And then when I looked at doing the actual
code patch, I ended up just running away scared.

           Linus