On Fri, Jul 31, 2026 at 10:03 AM Shrikanth Hegde <[email protected]> wrote:
> Coming into numbers, I did notice later, arm64 numbers are almost 20x less.
> But if we compare the time taken for each operations, it tells a
> different story.
Good catch. I investigated why the arm64 baseline is so much slower.
The 20x gap is due to cross-process signal delivery cost on the
128-core Ampere Altra Max, not preempt_count.
Self-kill (same process) vs cross-process kill on arm64:
self-kill (kill to self): 1.16 us/op (863k ops/sec)
cross-process kill: 54.06 us/op (18.5k ops/sec)
The stress-ng kill stressor sends signals between parent and child
processes, so it's dominated by the cross-process path (IPI, wakeup,
context switch). On the 128-core Ampere, this is expensive.
In contrast, the ppc64le test ran on 8 vCPUs sharing 1 physical core
(SMT-8 LPAR), where cross-thread signaling is much cheaper.
For reference, basic syscall latency (getppid) is only 1.6x different:
ppc64le POWER10: 0.106 us/op
aarch64 Ampere: 0.171 us/op
So the architectures are comparable for simple syscalls. The kill
stressor gap is about signal delivery topology, not CPU speed.
I also reran the arm64 tests with "taskset -c 0-7" to match the
ppc64le vCPU count. Results barely changed (kill uses only 2-3
threads), confirming this is not a core count issue but a cross-core
signaling cost:
With taskset -c 0-7 on arm64 (Ampere Altra Max, 6.18):
Kernel PREEMPT_RCU kill ops/sec us/op
---------------------- ----------- ------------ ------
6.18.0-vol-nodynamic no 6,171 162.0
6.18.0-vol-dynamic yes 5,477 182.6
Delta -11.2% +20.6 us/op
Updated per-operation comparison:
PREEMPT_DYNAMIC
ppc64le off 9.19 us/op
ppc64le on 14.66 us/op
delta +5.47 us/op
aarch64 off 162.0 us/op
aarch64 on 182.6 us/op
delta +20.6 us/op
The absolute delta is larger on arm64 (+20.6 us vs +5.47 us), but
as a percentage of total cost, ppc64le is hit harder (-37% vs -11%)
because its baseline is dominated by the syscall/security path where
preempt_count operations concentrate, whereas arm64's baseline is
dominated by signal delivery overhead that masks the preempt_count
cost.
The bottom line: PREEMPT_DYNAMIC/preempt_count overhead is present
on both RISC architectures but its visibility depends heavily on the
workload profile and hardware topology.
> PS: I tried porting some of those changes in arm64 to powerpc to
> split preempt count into two. but i don;t see much improvement
> there.
Thanks for trying. Paul questioned whether barriers are actually
needed for preempt_count, or whether software interrupt disabling
would suffice (his words: "I can see why the preempt_count()
operations need to be interrupt-safe, but I don't see why you would
need barriers"). Any thoughts on whether that's feasible for
powerpc?
Jirka
