Re: [REPORT] sched: ITMT + DELAY_DEQUEUE: woken task waits ~1 ms behind another task on the preferred CPU while allowed CPUs are idle

[Peter Zijlstra]

On Thu, Nov 12, 2026 at 09:59:02AM +0100, Vincent Guittot wrote:

> If the root problem is the migration of a delayed task during
> newly_idle load balance which transiently make the CPU not idle
> anymore for another task waking up simultaenously, can't we just
> prevent migrating delayed task for newly_idle case in can_migrate ?
> Migrating a delayed task to a newly idle CPU doesn't really make sense
> because it will be the only task that will e migrated and will be
> immediatly dequeued.

In fact, I would suggest just dequeuing it right then and there. If it
were actually runnable, it would get to run on the new idle cpu.
Therefore it is not contended anymore and its lag can be dropped.

> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -11771,7 +11771,7 @@ int can_migrate_task(struct task_struct *p,
> struct lb_env *env)
>          * 5) are cache-hot on their current CPU, or
>          * 6) are blocked on mutexes (if SCHED_PROXY_EXEC is enabled)
>          */
> -       if ((p->se.sched_delayed) && (env->migration_type != migrate_load))
> +       if ((p->se.sched_delayed) && (env->idle == CPU_NEWLY_IDLE ||
> env->migration_type != migrate_load))
>                 return 0;
> 
>         if (lb_throttled_hierarchy(p, env->dst_cpu))