linux-kernel - Re: [PATCH v2 01/23] sched/cache: Introduce 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: <c64a074c545d0069dbf4724e923c7c41d573ff9e.camel@linux.intel.com>
Date: Tue, 16 Dec 2025 14:30:03 -0800
From: Tim Chen <tim.c.chen@...ux.intel.com>
To: Vern Hao <haoxing990@...il.com>, 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>
Cc: 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>, Madadi Vineeth Reddy
 <vineethr@...ux.ibm.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>, Chen Yu	 <yu.c.chen@...el.com>, Adam Li
 <adamli@...amperecomputing.com>, Aaron Lu	 <ziqianlu@...edance.com>, Tim
 Chen <tim.c.chen@...el.com>, 	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 01/23] sched/cache: Introduce infrastructure for
 cache-aware load balancing

On Thu, 2025-12-11 at 16:42 +0800, Vern Hao wrote:
>  
> 
> 
> 
> 
snip

> > +		struct mm_sched __percpu *pcpu_sched;
> > +		raw_spinlock_t mm_sched_lock;
> > +		unsigned long mm_sched_epoch;
> > +		int mm_sched_cpu;
> >  
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> As we discussed earlier，I continue to believe that dedicating 'mm_sched_cpu' to handle the aggregated hotspots of all threads is inappropriate, as the multiple threads lack a necessary correlation in our real application. 
>  
> So, I was wondering if we could put this variable into struct task_struct, That allows us to better monitor the hotspot CPU of each thread, despite some details needing consideration.
>  
> 
> 
Vern,
The stat is related to the group of threads(tasks) that we will like to group
together in an LLC. In current implementation, it is per process and hence
the placement in mm struct.

Later, we could change the grouping to other criteria (e.g. cgroup, or numa_group).  In that
case the stats may be associated with other data struct that represent the
group.  As I mentioned in the cover letter, that would be another exercise and we'll
like to get the basic grouping by process to be merged first before considering other
kinds of grouping.

Tim

>