On Mon, Jul 27, 2026 at 09:48:25AM +0530, Shrikanth Hegde wrote:
> +cc paul for any further/RCU insights.
>
> On 7/27/26 12:03 AM, Jirka Hladky wrote:
> > Hi Shrikanth, Christophe,
> >
>
> Hi Jirka, thanks for the report.
>
> > I'm seeing a significant performance regression on ppc64le after this
> > patch landed in 6.16, caused by CONFIG_PREEMPT_RCU becoming active
> > once HAVE_PREEMPT_DYNAMIC_KEY is selected.
>
> This is true only if user selected PREEMPT_DYNAMIC option i think.
>
> config PREEMPT_RCU
> bool
> default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC)
> select TREE_RCU
Yes, if you select PREEMPT_DYNAMIC, RCU doesn't have much choice but to
choose PREEMPT_RCU. Something about not having the guts to implement an
RCU that dynamically switches between its preemptible and non-preemptible
variants. Cowardly of me, I know!
So if you want non-preemptible RCU, you need to turn off PREEMPT_DYNAMIC.
> > Benchmark: stress-ng kill stressor (tight kill() syscall loop),
> > single thread, POWER10 LPAR (8 vCPUs, 1 core SMT-8).
> >
> > Bisected across Fedora ELN kernel builds on ppc64le:
> >
> > kernel CONFIG_PREEMPT_RCU kill bogo-ops/sec
> > --- 6.15-rc6 (eln148) no 103,207
> > 6.16 (eln150) yes 70,281 (-32%)
> > 6.18 (eln154) yes 72,552 (-30%)
> >
>
> Does your preemption mode remain the same in two cases?
>
> > For comparison, x86_64 (AMD EPYC 9355P) with the same config change
> > shows only a 2.8% regression:
> >
> > 6.12 x86_64 37,436
> > 7.2 x86_64 36,392 (-2.8%)
> >
> > perf report shows the overhead comes from rcu_read_lock/unlock in the
> > SELinux AVC path (check_kill_permission -> security_task_kill ->
> > selinux_task_kill -> avc_has_perm -> avc_lookup):
> >
> > Function 6.15 (no PREEMPT_RCU) 6.16 (PREEMPT_RCU)
> > --- avc_lookup 15.23% 24.79%
> > __rcu_read_lock ~0% 4.52%
> > __rcu_read_unlock ~0% 4.17%
Yes, non-preemptible RCU's __rcu_read_{,un}lock() are (almost) no-ops,
but preemptible RCU must actually execute real code. But I would not
expect *this* much overhead.
> > selinux_task_kill 6.23% 7.35%
> > audit_signal_info* 0.94% 3.59%
> >
> > On x86_64, rcu_read_lock/unlock are cheap thanks to static calls
> > (HAVE_PREEMPT_DYNAMIC_CALL). On ppc64le with the KEY-based
> > implementation, the weak memory model requires real barriers
> > (lwsync/isync) making each RCU read-side critical section
> > significantly more expensive.
>
> Weak memory model would need barriers irrespective of
> HAVE_PREEMPT_DYNAMIC_CALL
> or HAVE_PREEMPT_DYNAMIC_KEY. That's my assumption. I will look
> more into it. Also i don't know much about PREEMPT_RCU. So might take a while.
OK, if you are executing an isync or an lwsync instruction in each call
to __rcu_read_{,un}lock(), that would explain the overhead.
CONFIG_PREEMPT_DYNAMIC=n for the win?
Thanx, Paul
> > This aligns with Christophe's earlier review comment that
> > HAVE_PREEMPT_DYNAMIC_CALL should be more performant. Would
> > implementing static calls for ppc64 be feasible to close this gap?
> >
>
> Static key too is expected to minimal cost. There maybe more into this.
>
> > Test details:
> > - Machine: IBM POWER10 (pvr 0080 0200), pHyp virtualization
> > - stress-ng 0.21.03, gcc 14.3.1, glibc 2.39
> > - Tuned profile: virtual-guest
> > - SELinux: enforcing (permissive recovers only ~7%)
> >
> > Happy to run additional tests if needed.
> >
> >
