linux-kernel - Re: [PATCH] sched/fair: Prefer cache-hot prev

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
 <MW6PR01MB83686E267D323D9012FAB53DF5F2A@MW6PR01MB8368.prod.exchangelabs.com>
Date: Wed, 22 Oct 2025 16:45:03 +0000
From: Shubhang Kaushik OS <Shubhang@...amperecomputing.com>
To: Phil Auld <pauld@...hat.com>
CC: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot
	<vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>,
	Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, Mel
 Gorman <mgorman@...e.de>, Valentin Schneider <vschneid@...hat.com>, Shubhang
 Kaushik <sh@...two.org>, Shijie Huang <Shijie.Huang@...erecomputing.com>,
	Frank Wang <zwang@...erecomputing.com>, Christopher Lameter <cl@...two.org>,
	Adam Li <adam.li@...erecomputing.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] sched/fair: Prefer cache-hot prev_cpu for wakeup

Hi Phil,

The fast-path optimization was designed to avoid costly load prediction and instead favor cache locality with a simple check. This trade-off yielded a small performance drop (~4%) in SPECjbb 2015, which benefits from aggressive load balancing. However, it maintained performance for cache-sensitive workloads, like AI inference (~3% improvement). We are investigating this balance between waker/wakee affinity and the overall load distribution to better understand its impact.

Best,
Shubhang
________________________________________
From: Phil Auld 
Sent: Monday, October 20, 2025 5:36 AM
To: Shubhang Kaushik OS
Cc: Ingo Molnar; Peter Zijlstra; Juri Lelli; Vincent Guittot; Dietmar Eggemann; Steven Rostedt; Ben Segall; Mel Gorman; Valentin Schneider; Shubhang Kaushik; Shijie Huang; Frank Wang; Christopher Lameter; Adam Li; linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched/fair: Prefer cache-hot prev_cpu for wakeup

Hi,

On Fri, Oct 17, 2025 at 04:00:44PM -0700 Shubhang Kaushik via B4 Relay wrote:
&gt; From: Shubhang Kaushik 
&gt;
&gt; Modify the wakeup path in `select_task_rq_fair()` to prioritize cache
&gt; locality for waking tasks. The previous fast path always attempted to
&gt; find an idle sibling, even if the task's prev CPU was not truly busy.
&gt;
&gt; The original problem was that under some circumstances, this could lead
&gt; to unnecessary task migrations away from a cache-hot core, even when
&gt; the task's prev CPU was a suitable candidate. The scheduler's internal
&gt; mechanism `cpu_overutilized()` provide an evaluation of CPU load.
&gt;
&gt; To address this, the wakeup heuristic is updated to check the status of
&gt; the task's `prev_cpu` first:
&gt; - If the `prev_cpu` is  not overutilized (as determined by
&gt;   `cpu_overutilized()`, via PELT), the task is woken up on
&gt;   its previous CPU. This leverages cache locality and avoids
&gt;   a potentially unnecessary migration.
&gt; - If the `prev_cpu` is considered busy or overutilized, the scheduler
&gt;   falls back to the existing behavior of searching for an idle sibling.
&gt;
&gt; Signed-off-by: Shubhang Kaushik 
&gt; ---
&gt; This patch optimizes the scheduler's wakeup path to prioritize cache
&gt; locality by keeping a task on its previous CPU if it is not overutilized,
&gt; falling back to a sibling search only when necessary.
&gt; ---
&gt;  kernel/sched/fair.c | 11 ++++++++++-
&gt;  1 file changed, 10 insertions(+), 1 deletion(-)
&gt;
&gt; diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
&gt; index bc0b7ce8a65d6bbe616953f530f7a02bb619537c..bb0d28d7d9872642cb5a4076caeb3ac9d8fe7bcd 100644
&gt; --- a/kernel/sched/fair.c
&gt; +++ b/kernel/sched/fair.c
&gt; @@ -8618,7 +8618,16 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int wake_flags)
&gt;               new_cpu = sched_balance_find_dst_cpu(sd, p, cpu, prev_cpu, sd_flag);
&gt;       } else if (wake_flags &amp; WF_TTWU) { /* XXX always ? */
&gt;               /* Fast path */
&gt; -             new_cpu = select_idle_sibling(p, prev_cpu, new_cpu);
&gt; +
&gt; +             /*
&gt; +              * Avoid wakeup on an overutilized CPU.
&gt; +              * If the previous CPU is not overloaded, retain the same for cache locality.
&gt; +              * Otherwise, search for an idle sibling.
&gt; +              */
&gt; +             if (!cpu_overutilized(prev_cpu))
&gt; +                     new_cpu = prev_cpu;
&gt; +             else
&gt; +                     new_cpu = select_idle_sibling(p, prev_cpu, new_cpu);

Won't this be checking if the cpu is overusitilzed without the wakee. It
might well be overutilized once the wakee is placed there.

I suspect this will hurt some workloads. Do you have numbers to share?


Cheers,
Phil


&gt;       }
&gt;       rcu_read_unlock();
&gt;
&gt;
&gt; ---
&gt; base-commit: 9b332cece987ee1790b2ed4c989e28162fa47860
&gt; change-id: 20251017-b4-sched-cfs-refactor-propagate-2c4a820998a4
&gt;
&gt; Best regards,
&gt; --
&gt; Shubhang Kaushik 
&gt;
&gt;
&gt;

--