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

[Pawan Gupta]

On Mon, Nov 02, 2026 at 06:43:58PM +0800, Chengfeng Lin wrote:
> Hi Pawan, Dave and Daniel,
> 
> I found another workload affected by a3af84b0fa00 while running MMTests:
> Redis ZPOPMIN throughput on v7.3 is about 13% lower than on v7.1.3.
> Unlike the repeated filter loading discussed here, the slowdown remains
> after the tasks that triggered the predictor flush (IBPB) have exited.
> Can this cost be reduced while preserving the security protection?
> 
> The machine is an i7-12700KF with 32 GiB RAM. All runs used CPU microcode
> 0x3e, and I did not disable any security mitigations. The test uses
> unmodified Redis 6.2.6 and MMTests' redis-benchmark-small recipe:
> 
>   redis-benchmark --csv -c 1 -r 50000 -n 100000 -P 256
> 
> There is one client, no CPU pinning, and all 20 logical CPUs are available.
> After each boot, I ran the full MMTests recipe nine times. Each run kept
> all 20 commands, including ZADD before ZPOPMIN, and the recipe's five
> internal repetitions:
> 
>                            v7.1.3 first       v7.3      v7.1.3 return
>   ZPOPMIN (requests/s)        999,366         871,397      1,000,947
>   GET (requests/s)          3,548,521       3,551,132      3,547,933
>   Complete test time (s)       61.396          61.704         61.301
> 
> ZPOPMIN is down 12.87% relative to the mean of the two v7.1.3 baselines.
> Within each boot, its coefficient of variation is below 0.75%; the two
> baselines differ by 0.16%.
> GET is essentially unchanged (+0.08%). The complete test, including
> startup and cleanup, takes 0.58% longer. The ZPOPMIN sequence drains the
> set without refilling it, so its request rate includes empty results,
> not just successful member removals.
> 
> Bisection identified a3af84b0fa00. To test the effect of a flush without
> changing kernel code, I used its parent, 96cce16e26dd, where Redis was
> still fast. On each CPU in turn, a short-lived helper enabled
> indirect-branch protection for itself using:
> 
>   prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH,
>         PR_SPEC_FORCE_DISABLE, 0L, 0L)
> 
> After all helpers exited, I started Redis from a controller whose
> protection setting was unchanged. Redis did not inherit the helpers'
> setting.
> 
> ZPOPMIN throughput fell by 11.06% and 11.69% on two separate boots.
> After another reboot, I ran the same helpers without changing their
> protection settings. Throughput returned to baseline (a 1.33% difference).

So am I understanding it correctly that with the same kernel(without BPF
JIT mitigation) and same workload configuration produced different
performance results accross boots?

Is it possible for you to repeat the test with a different microcode? If
the microcode is late-loaded in your setup you can use dis_ucode_ldr kernel
parameter to skip loading the microcode.