Thread (31 messages) read the whole thread 31 messages, 5 authors, 8h ago

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

From: Jirka Hladky <hidden>
Date: 2026-07-27 16:51:15
Also in: lkml

On Mon, Jul 27, 2026 at 6:16 PM Paul E. McKenney [off-list ref] wrote:
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.
I've now isolated the PREEMPT_RCU cost with a controlled experiment.
Built two kernels from the same 6.15-rc6 upstream source on the same
POWER10 machine, no CONFIG_PREEMPT_DYNAMIC in either case:

Config A: CONFIG_PREEMPT_VOLUNTARY=y (no PREEMPT_RCU)
Config B: CONFIG_PREEMPT=y           (PREEMPT_RCU=y)

Results (stress-ng --kill 1 -t 23, SELinux enforcing):

Kernel                       PREEMPT_RCU   kill bogo-ops/sec
---------------------------  -----------   -----------------
6.15-rc6-voluntary-test      no            105,014
6.15-rc6-preempt-test        yes            73,317
Delta                                      -30.2%

PREEMPT_RCU alone accounts for ~30% on this workload. The kill()
path hits rcu_read_lock/unlock very heavily through the SELinux AVC
(avc_has_perm -> avc_lookup wraps every hash table lookup in an RCU
read-side critical section).

This also answers Shrikanth's question about whether the regression
is from the preemption mode change (voluntary -> lazy) or from
PREEMPT_RCU. Since no PREEMPT_DYNAMIC is involved in either build,
the preemption mode is not a factor. Additionally, switching between
full and lazy at runtime on 7.1 showed only ~1% difference (57,476
vs 56,892), further confirming the mode doesn't matter.
OK, if you are executing an isync or an lwsync instruction in each call
to __rcu_read_{,un}lock(), that would explain the overhead.
Yes, that's what perf shows. __rcu_read_lock and __rcu_read_unlock
together consume ~9% of total cycles on ppc64le with PREEMPT_RCU,
vs essentially 0% without.
CONFIG_PREEMPT_DYNAMIC=n for the win?
That's the simplest distro workaround for ppc64le. But since commit
7dadeaa6e851 ("sched: Further restrict the preemption modes")
removed PREEMPT_VOLUNTARY as an option for architectures with
ARCH_HAS_PREEMPT_LAZY (which includes powerpc), distros that want
voluntary preemption on ppc64le would need to disable PREEMPT_DYNAMIC
anyway.

Is there any path to reducing the barrier cost in
__rcu_read_lock/__rcu_read_unlock on weakly-ordered architectures?
Or is the current implementation fundamentally constrained by the
memory model?

Jirka

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help