[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b8cb522a-83be-49ec-a4ca-5c084757fb67@arm.com>
Date: Fri, 31 Oct 2025 12:32:13 +0100
From: Dietmar Eggemann <dietmar.eggemann@....com>
To: Shubhang <sh@...two.org>, shubhang@...amperecomputing.com,
 Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
 Juri Lelli <juri.lelli@...hat.com>,
 Vincent Guittot <vincent.guittot@...aro.org>,
 Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>,
 Mel Gorman <mgorman@...e.de>, Valentin Schneider <vschneid@...hat.com>,
 Shijie Huang <Shijie.Huang@...erecomputing.com>,
 Frank Wang <zwang@...erecomputing.com>
Cc: Christopher Lameter <cl@...two.org>, Adam Li
 <adam.li@...erecomputing.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched/fair: Prefer cache-hot prev_cpu for wakeup
On 30.10.25 17:35, Shubhang wrote:
> The system is an 80 core Ampere Altra with a two-level
> sched domain topology. The MC domain contains all 80 cores.
Ah OK. So I assume the other SD is CLS with 2 CPUs?
Does this mean you guys have recently changed the sched topology on this
thing? I still remember setups with 2 CPUs in MC and 80 CPUs on PKG.
If this is the case, is:
db1e59483dfd - topology: make core_mask include at least
cluster_siblings (2022-04-20 Darren Hart)
still needed in this case?
> I agree that placing the condition earlier in `select_idle_sibling()`>
aligns better with convention. I will move the check (EAS Aware) to the
> top of the function and submit a v2 patch.
I can't imagine that you run EAS on this machine? It needs heterogeneous
CPUs which you shouldn't have. Looks like that Christian L. was asking
you already on your v2.
[...]
Powered by blists - more mailing lists
 
