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

Reply via email to