On Sun, 9 Nov 2025 at 11:55, Mateusz Guzik <[email protected]> wrote:
>
> I looked into this in the past, 64 definitely does not cut it.
We could easily make it be 128 bytes, I just picked 64 at random.
> Anyhow, given that the intent is to damage-control allocation cost, I
> have to point out there is a patchset to replace the current kmem
> alloc/free code with sheaves for everyone which promises better
> performance:
Oh, I'm sure sheaves will improve on the allocation path, but it's not
going to be even remotely near what a simple stack allocation will be.
Not just from an allocation cost standpoint, but just from D$ density.
But numbers talk, BS walks.
That said, I partly like my patch just because the current code in
getname_flags() is simply disgusting for all those historical reasons.
So even if we kept the allocation big - and didn't put it on the stack
- I think actually using a proper 'struct filename' allocation would
be a good change.
(That patch also avoids the double strncpy_from_user() for the long
path case, because once you don't play those odd allocation games with
"sometimes it's a 'struct filename', sometimes it's just the path
string", it's just simpler to do a fixed-size memcpy followed by a
"copy the rest of the filename from user space". Admittedly you can do
that with an overlapping 'memmove()' even with the current code, but
the code is just conceptually unnecessarily complicated for those
legacy reasons).
Linus
