On Fri, Oct 16, 2026 at 4:05 PM UTC, Alexei Starovoitov
<[email protected]> wrote:
> The test is flaky without -j too.
> It's in DENYLIST.s390x in CI since Dec 2025:
> https://github.com/kernel-patches/vmtest/pull/418
> and it fails on x86 with ASAN:
> https://github.com/kernel-patches/vmtest/issues/503
> Both jobs run test_progs without -j. serial_ won't help there.
Right. I timed the parts of the measurement on a KASAN kernel, x86_64
VM with 32 vCPUs, 30 runs each, median (max):
before 1st data shaped data after last data
idle 0.7ms (0.9ms) 200.08ms (201.9) 0.4ms (0.7ms)
32 busy loops 1.0ms (4.7ms) 200.08ms (200.4) 0.2ms (0.8ms)
The shaping itself is accurate. What eats the 2% margin, which is 4ms
of the 200ms transfer, is what send_recv_data() does before the first
byte goes out: creating the sender thread and accepting the connection.
That grows with how busy or slow the machine is.
To Alexis' questions: the misses are small, the test reports
"actual 2 > expected 2" and -2.4% was the worst here, and they do come
from CPU load. Widening the margin would only move the line, though, so
v2 [1] starts the measurement at the first packet with data instead,
which the BPF program notes. With 32 busy loops, 100 runs fail 3 times
before and none after.
[1]
https://lore.kernel.org/r/[email protected]
