Re: [PATCH v2] fs: cache the string generated by reading /proc/filesystems

[Mateusz Guzik]

On Thu, Apr 23, 2026 at 3:36 PM Christian Brauner <brauner@xxxxxxxxxx> wrote:
>
> On Wed, Apr 22, 2026 at 08:17:11PM +0200, Mateusz Guzik wrote:
> > It is being read surprisingly often (e.g., by mkdir, ls and even sed!).
> >
> > This is lock-protected pointer chasing over a linked list to pay for
> > sprintf for every fs (32 on my boxen).
> >
> > Instead cache the result.
> >
> > open+read+close cycle single-threaded (ops/s):
> > before:       442732
> > after:        1063462 (+140%)
> >
> > Here the main bottleneck is memcg.
> >
> > Scalability-wise problems are avoidable lockref trip on open and ref
> > management for the file on procfs side.
> >
> > The file looks like a sterotypical C from the 90s, right down to an
> > open-coded and slightly obfuscated linked list. I intentionally did not
> > clean up any of it -- I think the file will be best served by a Rust
> > rewrite when the time comes.
> >
> > Signed-off-by: Mateusz Guzik <mjguzik@xxxxxxxxx>
> > ---
>
> Ugh, can't we at least also get rid of the rwlock stuff?
> Something like the appended two (completely untested) patches.

The procfs thing got protest last time, see
https://lore.kernel.org/all/CACVxJT_eXRNjp-2sEfuxYmzTMPvu7U1R2bsKYjadVfR-W691og@xxxxxxxxxxxxxx/

Alexey wrote his own variant and put my name on it:
https://lore.kernel.org/linux-fsdevel/c58291cd-0775-4c90-8443-ba71897b5cbb@p183/
. I'm not going to protest the patch, but I'm not signing off on the
thing. Perhaps you can pull it while removing my credit? The author
cc'ed.

The wtf list handling cleanup + rwlock removal should certainly be
their own commit. applying all of this on top of my patch should be a
matter of few shell commands, alternatively I can massage this the
other way around.

I did not go for the other changes because a big chunk of the file is
the suspicious sysv syscall marked for removal and which I have 0
intentions of testing.

Finallly, a review did not like the BUG_ON (which you replaced with
WARN_ON_ONCE) and the new failure mode of ENOMEM. Both bogus
calculation and ENOMEM can be handled with a fallback to iterating the
list like it is done now.

I can do the massaging if it sounds like a plan.