Re: [PATCH] sched/stats: Fix run_delay over-count for proxy-migrated blocked donors

[albin_yang@163.com]

On Sun, Nov 01, 2026, Kayra Cizmeci wrote:
> IDK if you added the comment Peter asked for, if you didn't please
> add it in the final patch :-).

Yes -- I stripped them only for the email; the final patch keeps comments.

> It's up to Peter. Tho, makes sense to me if the other issue exists on
> older versions.

It does -- I booted a v6.12.115 kernel and ran the same reproducer
there, with and without the v4 patch already on the list:

    kernel                          run_delay delta    hit rate
    -----------------------------   -----------------  --------
    6.12.115, unpatched             147.98 - 147.99 ms  8/20
    6.12.115, + v4 (sched_delayed)    0.00 ms           0/100
    v7.3+ master, unpatched         147.94 - 147.99 ms  5/20
    v7.3+ master, + the diff          0.00 ms           0/100

Same setup in all four: DELAY_DEQUEUE on, two CPUs used -- worker and a
competitor on CPU0, main on CPU1 -- and main migrates the sleeping worker
with sched_setaffinity(). run_delay is schedstat field 2. The unpatched
delta matches the worker's own t_wake - t_migrate (147.99 vs 148.00 ms)
-- the whole sleep is charged. The reproducer self-checks (must reproduce
unpatched) and run_delay still grows ~40 ms per round, so the counter is
alive, not switched off.

None of this needs proxy exec -- v6.12 does not have it at all, so the
delayed dequeue over-count is fully independent of the proxy one. And
p->is_blocked only exists from v7.2: the is_blocked version cannot even
be built on 6.12, so with both folded into a single patch, v6.12.y to
v7.1.y has no fix at all.

The reproducer is plain userspace (no module); I can provide it if
needed.

Thanks,
Wei Yang