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

[albin_yang]

Hi Prateek,

Thanks - using is_blocked as the single indicator is certainly cleaner than
piling up exceptions.

I rebuilt your diff so it applies cleanly and gave it a run. I'm afraid it
does not work as-is in my testing - two problems:

1) sched_info_depart() now calls __sched_info_dequeue(), which no longer has
   the "if (!last_queued) return;" guard. A blocking task has last_queued == 0
   (sched_info_arrive() cleared it at switch-in), so delta becomes
   rq_clock(rq) - 0, i.e. the whole uptime:

     cross-cpu: blocked 169.80 ms, run_delay delta 169047.52 ms
     same-cpu:  blocked 168.70 ms, run_delay delta 185515.00 ms

   The control is affected too, so this is not proxy specific.

2) sched_info_enqueue() now arms only when t->is_blocked, leaving ordinary
   runnable tasks with no counter at all - my sanity check went from +39 ms to
   0.00 ms in every iteration, including the control. I do not think either
   polarity works: is_blocked is still set during the real wakeup enqueue
   (delayed sleeper: inside ttwu_runnable()'s is_blocked branch; donor: cleared
   only later by ttwu_do_wakeup()). So it can gate the charge side, but the
   arming side needs something already cleared at wakeup - task_is_blocked() or
   sched_delayed.

The delayed reproducer shows 0, but that is easy to misread: it measures only a
delta, and the bogus depart charge lands before the window. Its absolute
run_delay is polluted too. (The 0.00 ms sanity figure is from the proxy
reproducer, which carries that check.)

For reference, !sched_delayed && !task_is_blocked() gives 0.01 ms on the proxy
case with the sanity check intact (+39 ms), and 0/20 on the delayed reproducer.

Happy to retest whatever you come up with.

Thanks,
Wei Yang