Thread (21 messages) 21 messages, 4 authors, 1d ago

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

From: Shrikanth Hegde <hidden>
Date: 2026-07-27 04:19:10
Also in: lkml

+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

  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%
    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.
  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.
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help