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

[Mark Rutland]

On Mon, Jul 27, 2026 at 03:06:27PM -0700, 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.

None of that was in question.

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

In absolute terms, yes.

However, I'm fairly confident that the vast majority of the overhead we
have today can be eliminated with simpler alternatives.

There is a trade-off, and there are surprisingly complex interactions
between page tables and other things (e.g. entry code). There is risk
and maintenance burden associated with that. Hence people want to
understand how much of the benefit is attributable to what. So far, the
statements haven't convinced me people actually know what portion of the
overhead come from which factor, e.g.

* How much of that attributable to conditional work when re-enabling
  preemption?

* How much of that is attributable to RMW sequences to modify the
  preempt count itself?
 
* How much of that is attributable to system register accesses (SP_EL0
  and TPIDR_ELx)?

Any of those could easily dominate the other factors and might easily be
avoidable. Most of that should be measurable today. For example you
could restore the preempt_{enable,disable} calls atop Yang Shi's
patches.

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

It's true that the per-cpu page table approach will have fewer
instructions in the fast path.

However, the other statements here are potentially misleading:

(1) There is no restart in the scheme I have proposed, so restarting is
    irrelevant to the comparison.

(2) On x86, this_cpu*() operations use segment relative addressing, NOT
    per-cpu page tables. If arm64 had a similar addressing scheme, I
    expect we would use it.

(3) There are a number of novel problems associated with per-cpu page
    tables (e.g the various unsolved issues Yang has described), which
    do not apply to x86's implementation of this_cpu_*() operations.

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

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

While this simplifies the this_cpu_*() operations, I don't believe this
is a simplification overall, and IMO, describing it as such is
misleading.

Mark.