Re: [PATCH v4 1/1] powerpc: enable dynamic preemption
Jirka Hladky <[email protected]> Fri, 31 Jul 2026 15:50:36 +0200
| Newsgroups | org.ozlabs.lists.linuxppc-dev,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAE4VaGDQ0Ysdfhqc-eF9Oby-QkZxiL-TvS-WkJ_KKEVrRvTc7Q@mail.gmail.com> |
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