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

[Vincent Guittot]

On Thu, 12 Nov 2026 at 10:36, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> 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.

Yes, make sense to go even further

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