Re: [RFC v2 PATCH 0/16] Optimize this_cpu_*() ops for non-x86 (ARM64 for this series)

On Tue, 4 Aug 2026 at 09:30, Linus Torvalds
<[email protected]> wrote:
>
> Because people really have wanted to make it a "this is how the VM
> works" thing. And that is very much what I object to.

Side note: it's not that I object to small helper functions for some
common case that a couple of architectures take (ie arm64 and s390).

But I do object to what looks like some kind of "this is how
architectures should do it". Because I don't think that's the proper
path at all. This is an area where there are lots of commonalities,
but there are also cases where an architecture simply doesn't need it
at all (x86 segments are an example, but so is any architected base
register) or might take a completely different approach simply because
of how the architecture does TLB fills (ie different areas may have
simply different TLB walking: the pattern of "top few bits of the
virtual address picks between different "segments" - different from
x86 segments - is not that unusual afaik).

And I think David is right that there are different forms of this all,
where that kernel text is another special case where some particular
architectural choice might mean that it's trivially cheap to do *that*
entirely differently (typically because you know there are no writes,
and no aliasing issues).

So I'm just trying to clarify my stance - I don't hate percpu TLB
contents per se. I hate the notion of codifying them.

For example, if you have a SW-filled TLB - which is admittedly a
horribly broken idea even though it feels so clean and nice and has
been done multiple times - that changes how everything like this looks
for that architecture.

             Linus