linux-kernel - Re: [Patch] select_idle_sibling v.s. DELAYED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <897a4439-ece9-4935-bb7b-0d8aeb5c4e6b@amd.com>
Date: Mon, 24 Nov 2025 11:37:08 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: Tingjia Cao <tjcao980311@...il.com>, <peterz@...radead.org>, Vincent
 Guittot <vincent.guittot@...aro.org>, <mingo@...hat.com>,
	<juri.lelli@...hat.com>, <dietmar.eggemann@....com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [Patch] select_idle_sibling v.s. DELAYED_DEQUEUE

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