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

On Thu, Jul 30, 2026 at 02:08:54PM +0200, Jirka Hladky wrote:
> On Thu, Jul 30, 2026 at 8:44 AM Shrikanth Hegde <[email protected]> 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.

Good on all of you!

But is this really a fundamental RISC cost?  For example, does arm64
see the same performance issues?

In particular, I can see why the preempt_count() operations need to be
interrupt-safe, but I don't see why you would need barriers.  And doesn't
powerpc still use software interrupt disabling?  If so, why not use
that to simply software-disable interrupts around the preempt_count()
operations?

What am I missing here?

							Thanx, Paul