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

[Lorenzo Stoakes (ARM)]

On Tue, Aug 04, 2026 at 02:40:27PM -0700, Christoph Lameter (Ampere) wrote:
> On Tue, 4 Aug 2026, Lorenzo Stoakes (ARM) wrote:
>
> > On Tue, Aug 04, 2026 at 10:01:45AM -0700, Linus Torvalds wrote:
> > > 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.
> >
> > I do worry that changing per-CPU data structures to support this is exactly
> > codifying this (and will encourage other arches to follow suit).
> >
> > And I really don't think there's any way to implement this without
> > fundamentally changing core mm or assumptions that core mm can make.
>
> Would it be possible to discuss the technical issues instead of throwing
> up this and that foggy objection? Lets not get into the complexities of

Christoph this is very unhelpful. I and other maintainers have raised
_specific_ and _technical_ objections. If you are having comprehension
issues it'd be more constructive to ask questions.

It's really simple - convince us or the series doesn't go upstream.

>
> The fundamental problem is that your patchset does
>
>
> <preeamble establishing restart point>
> RMV per cpu op
> <post handling cleaning up setup of restart point>
>
>
> What x86 does and what we can get ARM to do is:
>
> RMW per cpu op
> Why do you think that your solution that requires a complex restart
> mechanism is better?
>
>
> These are operations that are key to the performance in critical parts of
> memory management and this code is replicated by being inlined thousands
> of times in the kernel.

I mean this is just silly :)

Provide data to back any of this, and no your benchmarks of your approach
vs. nothing isn't it, nor do they demonstrate anything about what you claim
here.

You've been asked for this multiple times now.

(And please no hand waving about 'critical parts of mm'. Be specific
please.)

>
>

--
Cheers, Lorenzo