[linus:master] [x86/bugs] a3af84b0fa: stress-ng.seccomp.ops_per_sec 95.7% regression

[linus:master] [x86/bugs] a3af84b0fa: stress-ng.seccomp.ops_per_sec 95.7% regression

[kernel test robot]

Hello,

kernel test robot noticed a 95.7% regression of stress-ng.seccomp.ops_per_sec on:

commit: a3af84b0fa00ead01fcd0e28b5d773ff25990a0d ("x86/bugs: Enable IBPB flush on BPF JIT allocation")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

testcase: stress-ng
config: x86_64-rhel-9.4
compiler: gcc-14
test machine: 256 threads 2 sockets Intel(R) Xeon(R) 6768P  CPU @ 2.4GHz (Granite Rapids) with 64G memory
parameters:

	nr_threads: 100%
	testtime: 60s
	test: seccomp
	cpufreq_governor: performance

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <yi1.lai@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202608191340.98574fe2-lkp@intel.com


Details are as below:
-------------------------------------------------------------------------------------------------->


The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260819/202608191340.98574fe2-lkp@intel.com

=========================================================================================
compiler/cpufreq_governor/kconfig/nr_threads/rootfs/tbox_group/test/testcase/testtime:
  gcc-14/performance/x86_64-rhel-9.4/100%/debian-13-x86_64-20250902.cgz/lkp-gnr-2sp4/seccomp/stress-ng/60s

commit: 
  96cce16e26 ("bpf: Support for hardening against JIT spraying")
  a3af84b0fa ("x86/bugs: Enable IBPB flush on BPF JIT allocation")
  b72e29e0f7 (bpf: Prefer dirty packs for eBPF allocations)

96cce16e26dd02a8 a3af84b0fa00ead01fcd0e28b5d b72e29e0f7ee329d89f86db8700
---------------- --------------------------- ---------------------------
         %stddev     %change         %stddev     %change         %stddev
             \          |                \          |                \
    351130           -95.7%      15233           -92.8%      25169        stress-ng.seccomp.ops
      5866           -95.7%     252.80           -92.9%     418.07        stress-ng.seccomp.ops_per_sec
    403577           -92.1%      31710           -88.5%      46510        stress-ng.time.involuntary_context_switches
  34288719 ±  2%     -95.4%    1594121           -92.5%    2566499        stress-ng.time.minor_page_faults
      4244           -67.9%       1363 ±  2%     -71.9%       1193        stress-ng.time.percent_of_cpu_this_job_got
      2515           -67.1%     826.95 ±  2%     -71.3%     721.20        stress-ng.time.system_time
     41.17 ±  2%     -94.9%       2.10 ±  3%     -91.7%       3.40 ±  2%  stress-ng.time.user_time
   1119583 ±  2%     -96.3%      40891           -94.5%      61287        stress-ng.time.voluntary_context_switches

Commit b72e29e0f7 slightly recovers performance but remains far below baseline.

Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.


-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [linus:master] [x86/bugs] a3af84b0fa: stress-ng.seccomp.ops_per_sec 95.7% regression

[Dave Hansen]

On 8/18/26 23:20, kernel test robot wrote:
> kernel test robot noticed a 95.7% regression of stress-ng.seccomp.ops_per_sec on:

One one level this is a "vulnerability mitigations cause performance
loss, news at 11" kind of thing. Like, Duh!

The microbenchmark here does seem to be a pretty worse-case scenario
where it sits in a loop loading and running a seccomp filter program. In
other words, it's just about as pathological of a test as you can have.

I think Pawan had some more ideas about ways to optimize this. Is there
any appetite for that? Or is the test just too synthetic to worry about?

Re: [linus:master] [x86/bugs] a3af84b0fa: stress-ng.seccomp.ops_per_sec 95.7% regression

[Pawan Gupta]

On Wed, Aug 19, 2026 at 08:26:53AM -0700, Dave Hansen wrote:
> On 8/18/26 23:20, kernel test robot wrote:
> > kernel test robot noticed a 95.7% regression of stress-ng.seccomp.ops_per_sec on:
> 
> One one level this is a "vulnerability mitigations cause performance
> loss, news at 11" kind of thing. Like, Duh!
> 
> The microbenchmark here does seem to be a pretty worse-case scenario
> where it sits in a loop loading and running a seccomp filter program. In
> other words, it's just about as pathological of a test as you can have.
> 
> I think Pawan had some more ideas about ways to optimize this. Is there
> any appetite for that? Or is the test just too synthetic to worry about?

One of the optimization is to do fine-grained tracking, i.e. track reuse
per-chunk instead of per-pack. This requires an additional bitmap per-pack.

Another option is to track the CPUs where the cBPF program ran, and only
send IPIs to those CPUs. This mainly reduces the overhead on workloads on
other CPUs, not necessarily the workload allocating programs. Seems more
relevant on servers with many CPUs.

Not sure if these are worth the effort yet, given that I am not aware of a
real-world workload with a significant impact.