On Sun, Nov 9, 2025 at 11:29 PM Linus Torvalds <[email protected]> wrote: > > On Sun, 9 Nov 2025 at 14:18, Mateusz Guzik <[email protected]> wrote: > > > > You would need 256 bytes to cover almost all of this. > > Why would you care to cover all of that? > > Your very numbers show that 128 bytes covers 97+% of all cases (and > 160 bytes is at 99.8%) > > The other cases need to be *correct*, of course, but not necessarily > optimized for. > > If we can do 97% of all filenames with a simple on-stack allocation, > that would be a huge win. > > (In fact, 64 bytes covers 90% of the cases according to your numbers). >
The programs which pass in these "too long" names just keep doing it, meaning with a stack-based scheme which forces an extra SMAP trip means they are permanently shafted. It's not that only a small % of their lookups is penalized. However, now that I wrote, I figured one could create a trivial heuristic: if a given process had too many long names in a row, switch to go directly to kmem going forward? Reset the flag on exec.
