Re: [PATCH] sched/stats: Fix run_delay over-count for migrated sched_delayed tasks

[albin_yang@163.com]

Hi,

To make the bug more concrete, I wrote a userspace reproducer
(available on request) that exercises exactly the path described in the
commit.

Setup: the system needs enough CPU pressure for the worker to become
!entity_eligible and take the delayed-dequeue path. In my runs I first
start background load, e.g.:

    stress-ng --cpu $(( $(nproc) - 1 )) &

The reproducer itself also pins a busy competitor thread to CPU0 for the
same reason.

What the reproducer does:

  - A worker thread burns ~80 ms of CPU on CPU0 then usleep()s for
    150 ms. With the background load keeping min_vruntime ahead, when
    the worker sleeps it is !entity_eligible and is kept on the rq with
    se.sched_delayed set (delayed dequeue) - still "sleeping" but not
    really runnable.
  - A separate thread migrates the worker to CPU1 with
    sched_setaffinity(worker_tid, cpu1) ~2 ms after it goes to sleep.
    This takes the plain migration path (activate_task(dst, 0)), which
    re-arms last_queued at the migration time while the task is still
    sleeping.
  - run_delay is read from /proc/<tid>/schedstat right before the
    migration and again after the worker actually wakes up and is
    scheduled.

Observed result (20 iterations; run_delay delta in ms):

    iter   run_delay   expected_err   verdict
      1      148.03      148.12        BUG
      4      148.88      148.93        BUG
      6      148.05      148.12        BUG
      9      148.88      148.93        BUG
     11      148.06      148.12        BUG
     14      148.89      148.93        BUG
     16      148.03      148.08        BUG
     17      148.89      148.94        BUG
   (others)     0.00      148.00        ok

Every migration that lands during the sched_delayed sleep charges
~148 ms of phantom wait into run_delay - i.e. the *entire* sleep
duration between migration and wakeup. With the patch, run_delay
delta stays ~0 in all iterations.

So this is a real, user-visible run_delay over-count, not just a
theoretical one. The fix is the single-line change in
sched_info_enqueue().

Would appreciate a review / any feedback. Happy to share the full
reproducer if that helps.

Original patch:
https://lore.kernel.org/all/20260909133345.1572954-1-albin_yang@163.com/

Thanks,
Wei Yang