linux-kernel - Re: [PATCH 01/19] sched/fair: Add infrastructure for cache-aware load balancing

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <b5975dbd-763b-4312-9167-feb2013d2968@intel.com>
Date: Thu, 16 Oct 2025 11:11:12 +0800
From: "Chen, Yu C" <yu.c.chen@...el.com>
To: Tim Chen <tim.c.chen@...ux.intel.com>, Madadi Vineeth Reddy
	<vineethr@...ux.ibm.com>
CC: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, "K
 Prateek Nayak" <kprateek.nayak@....com>, "Gautham R . Shenoy"
	<gautham.shenoy@....com>, Vincent Guittot <vincent.guittot@...aro.org>, "Juri
 Lelli" <juri.lelli@...hat.com>, 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>, "Hillf
 Danton" <hdanton@...a.com>, Shrikanth Hegde <sshegde@...ux.ibm.com>,
	"Jianyong Wu" <jianyong.wu@...look.com>, Yangyu Chen <cyy@...self.name>,
	Tingyin Duan <tingyin.duan@...il.com>, Vern Hao <vernhao@...cent.com>, Len
 Brown <len.brown@...el.com>, Aubrey Li <aubrey.li@...el.com>, Zhao Liu
	<zhao1.liu@...el.com>, Chen Yu <yu.chen.surf@...il.com>, Adam Li
	<adamli@...amperecomputing.com>, Tim Chen <tim.c.chen@...el.com>,
	<linux-kernel@...r.kernel.org>, <haoxing990@...il.com>
Subject: Re: [PATCH 01/19] sched/fair: Add infrastructure for cache-aware load
 balancing

On 10/16/2025 3:32 AM, Tim Chen wrote:
> On Wed, 2025-10-15 at 12:54 +0800, Chen, Yu C wrote:
>> On 10/15/2025 3:12 AM, Madadi Vineeth Reddy wrote:
>>> On 11/10/25 23:54, Tim Chen wrote:
>>>> From: "Peter Zijlstra (Intel)" <peterz@...radead.org>

[snip]

>>>
>>> How does it handle when cache locality and memory locality conflict?
>>> Shouldn't numa preferred node get preference? Also scanning multiple
>>> nodes add overhead, so can restricting it to numa preferred node be
>>> better and scan others only when there is no numa preferred node?
>>>
>>
>> Basically, yes, you're right. Ideally, we should prioritize the NUMA
>> preferred node as the top priority. There's one case I find hard to
>> handle: the NUMA preferred node is per task rather than per process.
>> It's possible that different threads of the same process have different
>> preferred nodes; as a result, the process-wide preferred LLC could bounce
>> between different nodes, which might cause costly task migrations across
>> nodes. As a workaround, we tried to keep the scan CPU mask covering the
>> process's current preferred LLC to ensure the old preferred LLC is included
>> in the candidates. After all, we have a 2X threshold for switching the
>> preferred LLC.
> 
> If tasks in a process had different preferred nodes, they would
> belong to different numa_groups, and majority of their data would
> be from different NUMA nodes.
> 
> To resolve such conflict, we'll need to change the aggregation of tasks by
> process, to aggregation of tasks by numa_group when NUMA balancing is
> enabled.  This probably makes more sense as tasks in a numa_group
> have more shared data and would benefit from co-locating in the
> same cache.
> 

Yes, this could be an enhancement if the NUMA balance is enabled.

thanks,
Chenyu