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

From: Christoph Lameter (Ampere)

Date: Tue Aug 18 2026 - 13:02:38 EST


On Thu, 6 Aug 2026, Lorenzo Stoakes (ARM) wrote:

> 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.

Changing a register used by code sometimes in a timer interrupt is
cleaner than accessing a virtually mapped address?

A simple RMV instruction is simpler and cleaner than prefixing a code
sequence with flags on how to modify registers if something happens like a
timer interrupt.

> Let's hope sanity prevails.

I sure hope so. But there is the ingroup behavior that rationalizes the
wildest approaches as sane.

> > 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).

The numbers are already approaching 20% and will go much higher because
there is more potential here with the ability to localize various memory
accesses in the future.

Scaling to large core counts requires the reduction of traffic on the
fabric connecting the cores. And the per cpu page tables allow that to
happen and scale to high core counts while minimizing traffc.

If you keep on with your hacky approach of changing registers in the tick
then we wont be getting there. We may have entirely new classes of bugs
because now the timer interrupts changes some registers. Think of the
hacking potential. Wow.

Please stop the madness.