Re: [LSF/MM/BPF TOPIC] Improve this_cpu_ops performance for ARM64 (and potentially other architectures)

[Yang Shi <yang@os.amperecomputing.com>]

On 2/23/26 1:50 AM, Heiko Carstens wrote:
> On Wed, Feb 11, 2026 at 03:14:57PM -0800, Yang Shi wrote:
>> Design
>> ======
>> To improve the performance for this_cpu_ops on ARM64 and potentially
>> some other non-x86 architectures, I and Christopher Lameter proposed
>> the below solution.
> ...
>
>> I have done some PoC on ARM64. Hopefully I can post them to the
>> mailing list to ease the discussion before the conference.
> FWIW, from an s390 perspective we have been relying on that preempt_disable()
> and preempt_enable() pairs for this_cpu*() ops are optimized away at compile
> time for PREEMPT_NONE and PREEMPT_VOLUNTARY. Which is what all distributions
> did, until now.
>
> With 7dadeaa6e851 ("sched: Further restrict the preemption modes") this is not
> the case anymore. So the overhead will be there for every "up-to-date"
> architecture except x86. I've been looking at some ways how to get rid of this
> extra overhead for s390. E.g. we have an "access register mode", which can be
> sort of compared to the x86 segment register approach, but switching the CPU
> to this mode and back is more expensive than the preempt_disable() and
> preempt_enable() pairs.

If I read the code correctly, preempt_disable/enable are *NOT* no-op on 
arm64 even though PREEMPT_VOLUNTARY is enabled. I tested with 
CONFIG_PREEMPT (should be called PREEMPT_FULL before), I saw roughly 2% 
more real time improvement on kernel build workload comparing to 
PREEMPT_VOLUNTARY. The improvement for sys time basically stays same.

>
> To make the long story short: I'm very interested in your approch from an s390
> perspective (aka "other non-x86 architectures").

Thanks for showing interest. Hopefully I can cleanup the patches, then 
post them to the mailing list before LSF/MM so that people can test it 
on other architectures, for example, s390. But it may still have a lot 
hack and ad hoc code.

Thanks,
Yang