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

From: Mukesh Kumar Chaurasiya

Date: Thu Jul 30 2026 - 06:05:54 EST


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