Re: [Patch] select_idle_sibling v.s. DELAYED_DEQUEUE

[K Prateek Nayak <kprateek.nayak@amd.com>]

Hello Tingjia,

On 11/23/2025 9:34 AM, Tingjia Cao wrote:
> Recently, we encountered an issue that sync wakeup kthread didn't choose the current CPU though the waker is the only runnable task. It is caused by a conflict between delayed dequeue feature and select_idle_sibling function.
> 
> With the DELAYED_DEQUEUE mechanism enabled, a task that goes to sleep may not be removed from the runqueue immediately. As a result, nr_running may overcount the number of runnable tasks. Inside select_idle_sibling, there is a special case for sync wakeup:
> 
> if (is_per_cpu_kthread(current) &&
>     in_task() &&
>     prev == smp_processor_id() &&
>     this_rq()->nr_running <= 1 &&
>     asym_fits_cpu(...)) {
>     return prev;
> }
> 
> For "this_rq()->nr_running <= 1": we should use the real running-tasks rq to check whether to place the wake-up task to the current cpu.
> 
> To fix this (patch attached), we can use the true number of runnable tasks by subtracting the delayed-dequeue count:
> 
>         this_rq()->nr_running - cfs_h_nr_delayed(this_rq()) <= 1

This is a very transient state - tasks cannot be delayed without other
runnable tasks at the time of dequeue and soon after the dequeue of
last runnable task, all the pending delayed tasks would get dequeued.
The window is actually very small. Does this make a difference in
your workload performance?

Once all tasks are dequeued, the newidle balance should run on the CPU
going idle to help reduce any imbalance.

-- 
Thanks and Regards,
Prateek