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

[Chen Yu <chen.yu@linux.dev>]

On Wed, Sep 09, 2026 at 09:33:45PM +0800, albin_yang@163.com wrote:
> Date: Wed,  9 Sep 2026 21:33:45 +0800
> From: albin_yang@163.com
> To: peterz@infradead.org, mingo@redhat.com, juri.lelli@redhat.com,
>  vincent.guittot@linaro.org
> Cc: dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com,
>  mgorman@suse.de, vschneid@redhat.com, kprateek.nayak@amd.com,
>  linux-kernel@vger.kernel.org, albinwyang@tencent.com
> Subject: [PATCH] sched/stats: Fix run_delay over-count for migrated
>  sched_delayed tasks
> X-Mailer: git-send-email 2.43.7
> 
> From: Wei Yang <albinwyang@tencent.com>
> 
> With DELAY_DEQUEUE, a blocked task stays on the runqueue with
> se.sched_delayed set and its sched_info.last_queued is cleared, so the sleep
> is not counted into run_delay.

Agree.
The sched_info.last_queued was cleared when that blocked task
switched in on the CPU, its last_queued was cleared in sched_info_arrive(),
because the task did not have to wait/delay anymore, it seems to be me that
the "delayed status" has nothing to do with "run_delay". The issue is what is
the realy timestamp of the task starts to wait.

> 
> When such a delayed (sleeping) task is migrated across CPUs via the plain
> migration paths (move_queued_task / move_queued_task_locked, the latter used
> by __migrate_swap_task), 

Right, for all the migration caused by passive/active load balance(attach_task,
with migrate_load type, see can_migrate_task()), NUMA balancing, CPU affinity changes
via sched_setaffinity(move_queued_task), etc, we should not update the "delayed"
task's last_queued field when enqueuing it on a new CPU - afterall it is not ready
for running.

> activate_task(dst, 0) calls enqueue_task() without
> ENQUEUE_RESTORE, re-arming last_queued to the migration timestamp while the
> task is still sleeping. The later real wakeup (ENQUEUE_DELAYED) tries to
> re-arm last_queued at wakeup time but is suppressed because last_queued is
> already non-zero, so sched_info_arrive() folds the whole sleep duration
> between migration and wakeup into run_delay.
> 
> Fix by not re-arming last_queued for a sched_delayed task in
> sched_info_enqueue(). The wakeup path clears sched_delayed before reaching
> sched_info_enqueue(), so it still re-arms at the real wakeup time. Plain
> runnable tasks and load-balance migrations are unaffected (sched_delayed
> tasks are excluded from active load balancing).
> 
> Fixes: 152e11f6df29 ("sched/fair: Implement delayed dequeue")
> Signed-off-by: Wei Yang <albinwyang@tencent.com>

Per my understanding, it looks good to me,

Reviewed-by: Chen Yu <yu.c.chen@intel.com>

thanks,
Chenyu