Re: [PATCH v2 00/20] arm64: Preemptible this_cpu_*() operations

[David Laight <david.laight.linux@gmail.com>]

On Wed, 2 Sep 2026 16:42:50 +0100
David Laight <david.laight.linux@gmail.com> wrote:

> On Wed, 2 Sep 2026 12:55:12 +0100
> Usama Anjum <usama.anjum@arm.com> wrote:
> 
> > On 04/08/2026 6:04 pm, Mark Rutland wrote:  
> > > This series reworks arm64's this_cpu_*() operations such that they do
> > > not need to disable preemption, avoiding related overhead in the fast
> > > paths. Instead, the ops begin/end a "PCPU GPR" critical section using
> > > unconditional/posted stores, which should be very cheap on any
> > > reasonable micro-architecture. During a critical section, should a
> > > (preemptible) exception be taken, the entry code will apply a fixup to
> > > the GPRs containing the percpu offset and the generated percpu address.  
> ...
> > tl;dr
> > Comparing this series with the page-table series [a] gives 8 improvements and 3
> > regressions.
> > 
> > Fastpath is a Linux kernel performance benchmarking service. The table
> > compares the both patched kernels: positive values are faster, negative
> > values are slower, and (I)/(R) indicate statistically significant
> > improvements/regressions. Unmarked differences are not significant after
> > accounting for confidence and noise thresholds.
> > 
> > +---------------------------------+--------------------+-----------------+-----------------------+
> > | Benchmark                       | percpu-pgtable [2] |   gpr-fixup [3] |         gpr-fixup [3] |
> > |                                 |    vs baseline [1] | vs baseline [1] | vs percpu-pgtable [2] |
> > +=================================+====================+=================+=======================+  
> ...
> > | perf/futex                      |              0.55% |      (R) -2.80% |            (R) -3.34% |
> > | perf/sched                      |          (I) 1.61% |          -0.39% |            (R) -1.97% |  
> 
> Might be worth investigating those two.
> Something odd is probably happening.

Answering myself :-)
Do I remember something about the code being locally faster actually
causing a slow down because it changed the paths the other cpu used?

> 
> David
>