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

[K Prateek Nayak <kprateek.nayak@amd.com>]

Hello Wei,

On 10/26/2026 7:08 PM, albin_yang@163.com wrote:
> 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

Thank you for testing the changes!

> 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.

Ah! That is an oversight. I didn't realise arrive clears the last_queued
and yes, doing it unconditionally will account the full uptime.

> 
> 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.

Ack! I forgot task migrations. So based on a better look, all we have to
do i start accounting when the task becomes runnable again (p->is_blocked
is cleared) and don't account any time when the task is "on_rq" while
being blocked (p->is_blocked && p->on_rq).

> 
> 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.

So all things considered, I think the following should work unless I'm
terribly mistaken yet again :-) I've left my reasoning as comments:

diff --git a/kernel/sched/stats.h b/kernel/sched/stats.h
index ebe0a7765f98..c4c624deb25b 100644
--- a/kernel/sched/stats.h
+++ b/kernel/sched/stats.h
@@ -239,6 +239,15 @@ static inline void psi_account_irqtime(struct rq *rq, struct task_struct *curr,
 static inline void sched_info_dequeue(struct rq *rq, struct task_struct *t)
 {
 	unsigned long long delta = 0;
+	/*
+	 * If a task is blocked (blocked donor, delayed dequeue task),
+	 * do not account the queued time as runnable. A task that is
+	 * blocking would have already cleared the "last_queued"
+	 * indicator from sched_info_arrive() when it got a chance to
+	 * run on the CPU.
+	 */
+	if (t->is_blocked)
+		t->sched_info.last_queued = 0;
 
 	if (!t->sched_info.last_queued)
 		return;
@@ -290,7 +299,23 @@ static void sched_info_arrive(struct rq *rq, struct task_struct *t)
  */
 static inline void sched_info_enqueue(struct rq *rq, struct task_struct *t)
 {
-	if (!t->sched_info.last_queued)
+	/*
+	 * "t->is_blocked" is only cleared after the enqueue is done and
+	 * the task is woken up. If the task is blocked, update the
+	 * "last_queued" timestamp to that of last enqueue - if the task
+	 * is still blocked while it leaves the runqueue, this timestamp
+	 * is ignored and is cleared at sched_info_dequeue().
+	 *
+	 * To transition a task back to blocked after wakeup, it has to
+	 * run on the CPU and naturally reach a safe preemption point.
+	 * sched_info_arrive() will do the correct wait time accounting
+	 * based on the last "last_queued".
+	 *
+	 * Any movement of task after being marked not blocked will be
+	 * correctly captured as queued time at enqueue + dequeue
+	 * boundaries when "t->is_blocked" cleared.
+	 */
+	if (!t->sched_info.last_queued || t->is_blocked)
 		t->sched_info.last_queued = rq_clock(rq);
 }
 
---

That "t->is_blocked" check in sched_info_enqueue() may not be
necessary either but I've left it in there for now since I did my
quick testing with it.

-- 
Thanks and Regards,
Prateek