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

[K Prateek Nayak]

Hello Francesco,

On 11/5/2026 1:42 PM, Francesco Nigro wrote:
> [You don't often get email from nigro.fra@xxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Thu, 2026-11-05 at 09:41 +0530, K Prateek Nayak wrote:
>> Hello Francesco,
> 
> Hi Prateek,
> 
> thanks a lot for looking into this, and for the patch.
> 
> This is a corporate machine, so I can't promise I will be able to boot
> a patched kernel on it, but I will try.

No worries I'll try it on my end over the coming weekend.
 
>> Since you say ITMT disabled actually solves this issue, I suspect there is a
>> race between the idle balancer moving the delayed task to a preferred CPU vs
>> a wakeup that also lands on the same CPU.
> 
> perf sched shows a race like that, but the task moved is the running
> one, by active balance. One example (perf sched timehist, trimmed; ms):
> 
>     .654334  [6]  worker 482   awakened: migration/7
>     .654337  [6]  worker 482   blocks

I'm having a hard time understanding why asym_active_balance() would
trigger before worker 482 blocks - also I'm assuming at this point
482 is the only task on the CPU so it shouldn't get delayed since
single task on CPU is always eligible.

>     .654338  [7]  worker 481   preempted while running
>     .654341  [7]  migration/7  migrated: worker 481 cpu 7 => 6
>     .654341  [2]  waker        awakened: worker 482
>     .655572  [6]  worker 482   ran 1.006 after 0.224 sch delay
> 
> Does your change cover the active balance path too?

I think I was missing the other part of allowing a delayed task to
migrate with the following diff:

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index b8c26a6ca82d..71dd82394006 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -11133,14 +11133,16 @@ int can_migrate_task(struct task_struct *p, struct lb_env *env)
 
 	/*
 	 * We do not migrate tasks that are:
-	 * 1) delayed dequeued unless we migrate load, or
+	 * 1) delayed dequeued unless we migrate load / migration to idle CPU, or
 	 * 2) target cfs_rq is in throttled hierarchy, or
 	 * 3) cannot be migrated to this CPU due to cpus_ptr, or
 	 * 4) running (obviously), or
 	 * 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->flags & LBF_FIRST_MIGRATION) &&
+	     env->migration_type != migrate_load))
 		return 0;
 
 	if (lb_throttled_hierarchy(p, env->dst_cpu))
---

This should allow for an idle CPU to see a delayed task and block it
even if it is has not yet hit the "migrate_load" threshold but it
still doesn't explain why the active balance gets triggered before
blocking.


>> So at this point, I would have expected B to have already been
>> moved by a newidle / idle balance.
> 
> Not here: in 270 of 286 waits of 0.5 ms or more, neither worker left
> CPU 6, and CPUs 4, 5 and 7 were idle for at least 98 % of the wait.
> 
> Trace summary and excerpt:
> https://github.com/franz1981/itmt-delay-dequeue-repro/tree/827b6b2

Thank you! Give me a wee bit more time to trace this path and I'll get
back to you by next week. Thank you again for all the data.

-- 
Thanks and Regards,
Prateek