On Sun, Nov 9, 2025 at 9:22 PM Linus Torvalds
<[email protected]> wrote:
>
> 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.
>
I see I neglected to mention, the lengths I had seen were untenable
for a stack-based allocation. Going with a smaller on-stack buf means
having to retry with an extra SMAP trip which probably makes it a
no-go.
While I can't easily redo the survey on Linux, here is a taste from 10
minutes of package building on FreeBSD. A histogram of lengths with a
step of 8, rounded down.
You would need 256 bytes to cover almost all of this. Maybe 192-ish is
a bare minimum where the idea is likely a win? But even then the
people who want 8K stacks probably wont be able to use the feature to
begin with.
dtrace -n 'vfs:namei:lookup:entry { @ =
lquantize(strlen(stringof(arg1)), 0, 384, 8); }'
value ------------- Distribution ------------- count
< 0 | 0
0 |@@@@@@@@ 18105105
8 |@@@@@@@ 16360012
16 |@@@@@@@@@ 21313430
24 |@@@@@@ 15000426
32 |@@@ 6450202
40 |@@ 4209166
48 |@ 2533298
56 |@ 1611506
64 |@ 1203825
72 | 1068207
80 | 877158
88 | 592192
96 | 489958
104 | 709757
112 | 925775
120 | 1041627
128 |@ 1315123
136 | 664687
144 | 276673
152 | 150870
160 | 82661
168 | 40630
176 | 26693
184 | 15112
192 | 7276
200 | 5773
208 | 2462
216 | 1679
224 | 1150
232 | 1301
240 | 1652
248 | 659
256 | 464
264 | 0
> > 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.
>
I completely agree, but per the above the sizes look unwieldy for the
stack. This is something I tried to do years back and backed off due
to that reason.
> 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.
>
I don't know of anyone is fond of the current code. ;)
