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

[Lorenzo Stoakes (ARM)]

On Thu, Aug 06, 2026 at 06:15:35PM +0100, Will Deacon wrote:
> So the nice thing about having two implementations (i.e. the per-cpu
> page-tables *and* the preemption stuff from Mark) is that we can pitch
> them against each other to help us make a decision.

Yes exactly :)

This point has been put to the submitters a number of times so I hope that
an additional repetition from an arm64 maintainer helps underline it.

>
> However, I don't see how anybody could argue that Mark's series isn't
> cleaner and easier to maintain.

I completely agree.

> I've seen it described as "hacky" but I
> can't tell whether or not that's supposed to be a criticism. If we

Allow me to translate: 'I want to ignore this' :)

Similarly the comment about mm maintainers wanting maintainable not-broken
code being a 'foggy' position. Translation: 'I want to ignore this'.

Since maintainers decide what gets merged the translation gets flipped
if the submitters fail to address the feedback.

Let's hope sanity prevails.

> seriously want to consider the per-cpu page-table approach on arm64, the
> numbers need to be _really_ good and across a variety of hardware, not
> just the stuff with a memory system made of baling twine. That extends
> to the kernel text replication efforts too.

Thanks, and equally so for the core mm changes that are required by the
page table approach (that requirement being attested to by the diffstat).

>
> Will

--
Cheers, Lorenzo