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

[Kayra Cizmeci <kayracizmeci@gmail.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.

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

No? can_migrate_task() skips delayed tasks unless they are both delayed and 
migration_type not equals migrate_load. 

And can_migrate_task() is called from detach_one_task() which
gets called from active_load_balance_cpu_stop(), with a custom
env where the migration type is not set. That means, the migration
type is migrate_load, and can_migrate_task() can return 1 for delayed
tasks on this path. 

> Fixes: 152e11f6df29 ("sched/fair: Implement delayed dequeue")
> Signed-off-by: Wei Yang <albinwyang@tencent.com>

Thanks,
Kayra :>