Re: [PATCH v5 0/8] Generic IRQ entry/exit support for powerpc

On Mon, Jul 27, 2026 at 11:41:07AM +0200, Jirka Hladky wrote:

Hi Mukesh, Shrikanth, Madhavan,

I'm seeing a ~19% throughput regression on ppc64le (POWER10) in
syscall-heavy workloads between kernel 7.1 and 7.2-rc4, which I've
narrowed down to the GENERIC_ENTRY enablement for powerpc (commit
bee25f97ad24 "powerpc: Enable GENERIC_ENTRY feature").

The regression manifests specifically when SELinux is enabled. Regression
disappears with selinux=0. With SELinux disabled, 7.2 is actually
slightly *faster* than 7.1.

Test: stress-ng --kill 1 -t 23 (single-thread kill() syscall loop)
Machine: IBM,9080-HEX POWER10, 8 vCPUs (1 core SMT-8), 64 GiB

Results (bogo-ops/sec, higher is better):

Kernel   Enforcing   Permissive   Disabled    SELinux tax
------   ---------   ----------   --------    -----------
7.1      69,107      70,248       93,566      -26.1%
7.2-rc4  56,247      59,075       99,240      -43.3%
Delta    -18.6%      -15.9%       +6.1%

Key observations:
- SELinux permissive ~ enforcing on both kernels (overhead is in the
  code path, not policy evaluation)
- SELinux disabled: 7.2 is 6% faster than 7.1 -- the generic entry
  path itself is not slower for the base syscall
- The SELinux "tax" nearly doubles from 26% to 43% between 7.1->7.2
- No changes to security/selinux/avc.c between v7.1 and v7.2-rc4

The kill() hot path (sys_kill -> check_kill_permission -> security_task_kill
-> selinux_task_kill -> avc_has_perm -> avc_lookup) wraps every AVC lookup
in rcu_read_lock()/rcu_read_unlock(). On ppc64le with PREEMPT_RCU, each
pair requires lwsync/isync barriers. I suspect the generic entry path
changes something in how context tracking, tracing, or RCU interacts
with the syscall fast path that amplifies the per-call RCU cost.

Note: this is on top of a separate ~36% regression from 6.12->7.1 caused
by HAVE_PREEMPT_DYNAMIC_KEY enabling CONFIG_PREEMPT_RCU on ppc64le
(commit 6ad7751537e8), which I reported separately on the v4 thread.

Thank you
Jirka

[...]
Hey Jirka,

Thanks for reporting this.
I'll take a look.

Thanks,
Mukesh