Re: [PATCH v4 1/1] powerpc: enable dynamic preemption

[Jirka Hladky]

On Thu, Jul 30, 2026 at 8:44 AM Shrikanth Hegde <sshegde@xxxxxxxxxxxxx> wrote:
> From the above, it is quite evident that main cost is cost of
> preempt_disable/preempt_enable due to inc/dec of preempt count
> itself.

Thanks for the deep debugging, Shrikanth. This changes the picture
significantly.

So the chain is:
  PREEMPT_DYNAMIC -> PREEMPTION -> PREEMPT_COUNT
  -> every preempt_disable/enable becomes load-modify-store with barriers

And the __rcu_read_lock/__rcu_read_unlock overhead I measured was
actually the preempt_disable/preempt_enable inside them, not the RCU
logic itself. That explains why removing PREEMPT_RCU only recovered
~5% -- the remaining preempt_count operations throughout the syscall
path are the dominant cost.

> The cost of preempt_count is likely un-avoidable with
> DYNAMIC_PREEMPTION for all RISC architecture.

Agreed. On CISC (x86), the preempt_count update is a single memory
inc/dec instruction. On RISC, it requires load-modify-store plus
barriers for the atomic update, which is fundamentally more expensive
per operation.

> Also given that after 7.0, all major archs including powerpc, can
> have only full/lazy preemption. None/voluntary are no longer possible.
> So making any sort of optimization for preempt count is not useful
> since it has to be there for full/lazy.

Right. With full/lazy, PREEMPT_COUNT is required regardless of
PREEMPT_DYNAMIC.

> Also, evaluate it with any real life workloads, IIRC i have run
> hackbench, schbench, daytrader(db2 workload) this cost wasn't visible.

Good to know. I reviewed our full CI results across all benchmark
suites on ppc64le and I don't see regressions outside of stress-ng. The
stress-ng kill stressor is a worst case -- a tight syscall loop that
hits preempt_disable/enable many times per call through the SELinux
AVC path. Real workloads that do actual work between syscalls
amortize this cost.

I'll update our internal tracking with the corrected root cause.

Thanks again for your persistence on isolating this. Good to have
the real root cause understood, even if it's a fundamental RISC cost
we have to accept.

Jirka