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

[albin_yang@163.com]

Hi Kayra,

On Sat, Sep 19, 2026 at 01:24:20PM +0300, Kayra Cizmeci wrote:
> 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.

You are right, thanks for catching this.

migrate_load is 0, and active_load_balance_cpu_stop()'s lb_env does not
set .migration_type, so it stays 0 == migrate_load. Hence in
can_migrate_task():

	if ((p->se.sched_delayed) && (env->migration_type != migrate_load))
		return 0;

the condition is false on that path, and a sched_delayed task can indeed
be migrated.

It is also a bit broader than the active balance case: load_balance() ->
calculate_imbalance() sets env->migration_type = migrate_load for some
group types, so regular load balance can hit it too. Either way those
paths re-attach via attach_task() -> activate_task(rq, p, ENQUEUE_NOCLOCK),
again without ENQUEUE_RESTORE, so they hit the same bug.

So the "load-balance migrations are unaffected" part of my commit message
is wrong. The fix itself is unchanged and covers those paths as well; only
the description was wrong. I'll correct it in v2.

Thanks,
Wei Yang