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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 7/28/26 00:06, Christoph Lameter (Ampere) wrote:
> 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.

Most of the features you mentioned above are not supposed to be
architecture-specific things. IIUC, Linus strongly objected per-cpu page tables
in the past, which suggests to me that such an arm64-only thing is not the way
to go?

-- 
Cheers,

David