On Sun, Nov 9, 2025 at 11:33 PM Mateusz Guzik <[email protected]> wrote: > > 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.
Geez, that was rather poorly stated. Let me try again: 1. The programs which pass long names just keep doing for majority of their lookups, meaning the extra overhead from failing to fit on the stack will be there for most of their syscalls. 2. I noted a heuristic could be added to detect these wankers and go straight to kmem in their case. One trivial idea is to bump a counter task_struct for every long name and dec for every short name, keep it bounded. If it goes past a threshold for long names, skip stack allocs. Then indeed a smaller on-stack buffer would be a great win overall.
