On Sun, Nov 30, 2025 at 5:06 AM Al Viro <[email protected]> wrote:
>
> On Sat, Nov 29, 2025 at 06:33:22PM +0100, Mateusz Guzik wrote:
>
> > This makes sizeof struct filename 152 bytes. At the same time because
> > of the SLAB_HWCACHE_ALIGN flag, the obj is going to take 192 bytes.
> >
> > I don't know what would be the nice way to handle this in Linux, but
> > as is this is just failing to take advantage of memory which is going
> > to get allocated anyway.
> >
> > Perhaps the macro could be bumped to 168 and the size checked with a
> > static assert on 64 bit platforms?
>
> Could be done, even though I wonder how much would that really save.
>
By any chance are you angling for that idea to keep struct filename on
the stack and that's why the size is 128?
With struct nameidata already on the stack and taking 240 bytes,
adding the 152 bytes would result in 392 bytes in total. I would argue
that's prohibitive, at the same time lowering the length to something
like 64 already makes gcc not fit with some of its lookups.
Anyway, I did look into something like this way back and some programs
really liked their *long* paths (way past 128).
Some stats I recently collected on FreeBSD while building packages:
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
> > Or some magic based on reported
> > cache line size.
>
> No comments. At least, none suitable for polite company.
>
> BTW, one thing that might make sense is storing the name length in there...
(gdb) ptype /o struct filename
/* offset | size */ type = struct filename {
/* 0 | 8 */ const char *name;
/* 8 | 8 */ const char *uptr;
/* 16 | 4 */ atomic_t refcnt;
/* XXX 4-byte hole */
/* 24 | 8 */ struct audit_names *aname;
/* 32 | 0 */ const char iname[];
/* total size (bytes): 32 */
}
If the length start getting stored it can presumably go into the hole.
Otherwise is there a reason to not rearrange this? The array could be
only aligned to 4 bytes, on archs which are fine with misaligned
access anyway. That's 4 extra bytes recovered.
All that said, now that I look at it, assuming struct filename will
keep being allocated from slub, why not make it 256 bytes? This gives
232 bytes for the name buffer (covering almost all of the looups I ran
into anyway), archs with 128 byte cacheline are sorted out and one can
trivially unconditionally static assert on the total size being 256
bytes, all while not having space which is never going to be used.
