Re: [RFC PATCH 00/15] kmem_cache instances with static storage duration

[Al Viro <viro@zeniv.linux.org.uk>]

On Fri, Jan 09, 2026 at 07:33:41PM -1000, Linus Torvalds wrote:
> On Fri, 9 Jan 2026 at 18:01, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> >         There's an alternative approach applicable at least to the caches
> > that are never destroyed, which covers a lot of them.  No matter what,
> > runtime_const for pointers is not going to be faster than plain &,
> > so if we had struct kmem_cache instances with static storage duration, we
> > would be at least no worse off than we are with runtime_const variants.
> 
> I like it. Much better than runtime_const for these things.
> 
> That said, I don't love the commit messages. "turn xyzzy
> static-duration" reads very oddly to me, and because I saw the emails
> out of order originally it just made me go "whaa?"
> 
> So can we please explain this some more obvious way. Maybe just "Make
> xyz be statically allocated". Yes, I'm nitpicking, but I feel like
> explaining core patches is worth the effort.

Point, but TBH the tail of the series is basically a demo for conversions
as well as "this is what I'd been testing, FSVO".  In non-RFC form these
would be folded into fewer commits, if nothing else...

I'd really like to hear comments on the first two commits from SLAB
maintainers - for example, if slab_flags_t bits are considered a scarce
resource, the second commit would need to be modified.  Still doable, but
representation would be more convoluted...

Another question is whether it's worth checking for accidental call
of e.g. kmem_cache_setup() on an already initialized cache, statically
or dynamically allocated.  Again, up to maintainers - their subsystem,
their preferences.