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

[Christoph Lameter (Ampere)]

On Wed, 22 Jul 2026, Mark Rutland wrote:

> I expect that should come with a reasonable benefit, but I don't have
> benchmark figures yet as I haven't finished converting the xchg and
> cmpxchg implementations.
>
> > It sounds like it just moved the cost from one place to the other
> > place and it also seems hacky TBH.


Yang Shi's patch has *no* critical section. There is no additional code
for the RMV instruction. The RMV instruction is executed on the correct
per cpu area. One of the reasons for the performance win is the
eliminattion of these critical sections. Your approach still has some form
of prologue and posthandling like the current preempt approach and
therefore will not be able to have the same performance gains.

The code is more efficient, there is no restart necessary and the
technique is already widely used on x86 for a long time.

Having the ability in general to map mmemory differently depending on the
cpu opens up a number of other optimization like

1. Per Node areas. Calculations of addresses for per node data and RMV
operations on per node data becomes as trivial as the per cpu data
handling. This will further reduce and eliminate critical sections
currently necessary to handle per node data modifications for NUMA
configurations which are increasingly becoming important for large core
configurations on ARM64.

2. Kernel text replication. Kernel text can be replicated per node or
per whatever memory is closer to the executing code. This avoids transfers
via the on chip memory busses and increases performance. We have seen
20-50% on that one.

3. Readonly data replication. A similar approach is possible for kernel
read only data.

3. Read-mostly replication. This is a bit more complex and the writes
become more expensive since updates have to be made to all copies but
a read-mostly variable is rarely written and the replication will reduce
the latencies to reach these variables.


4. Custom sets of cores that operate on shared data that is replicated
per node or some custom set of cores. This is for example
useful for network devices that have the ability to do I/O via a split
PCI bus or other construct where I/O lanes are duplicated to sets of
cores.


What we are proposing here is a basic new feature that simplifies code and
allows addititonal performance and functional features that are so far not
possible on ARM64.