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

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

On Tue, Jun 23, 2026 at 10:09:41AM +0200, Vlastimil Babka (SUSE) wrote:

> But the argument for doing the static duration support is that it should be
> faster, not just "not slower"? So is runtime_const equivalent or for some
> fundamental reason it's slower than plain &?

Yes, on any 64bit RISC.  And if nothing else, arm64 has enough users to care
about.  runtime_const for _shifts_ tends to be nice and easy; for pointers...
not really.

Compiler does *not* build the address of global variable in a sequence of
shifts and bitwise operations when it needs to pass it to a function.
runtime_const_ptr() must be able to handle an arbitrary address; it can't
avoid doing the general "build a 64bit value in register", which tends to
be nasty on RISC.

If you want real ugliness, take a look at riscv - AFAICS, they wanted to
avoid a long dependency chain, so they load chunks of constant into 4 registers,
then shift and combine those.  arm64 doesn't bother; IIRC, the hardware does
recognize this sequence, but I wouldn't swear on that.

> Or is the advantage that static caches can support modules and runtime_const
> can't?

Probably, but I'm not ready to give examples at the moment.  There definitely
used to be __getname() users in modules, but that stopped using names_cache.