RE: [RFC PATCH v2 07/23] sched/cache: Prioritize preferred NUMA node selection over LLC selection

[Jianyong Wu]

Hi Peter,

> -----Original Message-----
> From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Sent: Monday, August 31, 2026 9:17 PM
> To: Jianyong Wu <wujianyong@xxxxxxxx>
> Cc: Ingo Molnar <mingo@xxxxxxxxxx>; Juri Lelli <juri.lelli@xxxxxxxxxx>;
> Vincent Guittot <vincent.guittot@xxxxxxxxxx>; Chen Yu
> <yu.c.chen@xxxxxxxxx>; Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>; Dietmar
> Eggemann <dietmar.eggemann@xxxxxxx>; Steven Rostedt
> <rostedt@xxxxxxxxxxx>; Ben Segall <bsegall@xxxxxxxxxx>; Mel Gorman
> <mgorman@xxxxxxx>; Valentin Schneider <vschneid@xxxxxxxxxx>; K
> Prateek Nayak <kprateek.nayak@xxxxxxx>; Shrikanth Hegde
> <sshegde@xxxxxxxxxxxxx>; Phil Auld <pauld@xxxxxxxxxx>; Andrew
> Morton <akpm@xxxxxxxxxxxxxxxxxxxx>; David Hildenbrand
> <david@xxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; linux-mm@xxxxxxxxx;
> jianyong.wu@xxxxxxxxxxx; Yuan Zhong <zhongyuan@xxxxxxxx>; Huangsj
> <huangsj@xxxxxxxx>; Fengyu Wang <wangfengyu@xxxxxxxx>; Zhiwei Ying
> <yingzhiwei@xxxxxxxx>; justin.he@xxxxxxx
> Subject: Re: [RFC PATCH v2 07/23] sched/cache: Prioritize preferred NUMA
> node selection over LLC selection
> 
> On Thu, Aug 27, 2026 at 08:28:00PM +0800, Jianyong Wu wrote:
> 
> > +	/*
> > +	 * Avoid switching sc_stat.cpu too fast. The reason to choose 2X is
> > +	 * because:
> > +	 * 1. It is better to keep the preferred LLC stable, rather than
> > +	 *    changing it frequently and cause migrations
> > +	 * 2. 2X means the new preferred LLC has at least 1 more busy CPU
> than
> > +	 *    the old one(200% vs 100%, eg)
> > +	 * 3. 2X is chosen based on test results, as it delivers the optimal
> > +	 *    performance gain so far.
> > +	 *
> > +	 * Moving to another node takes precedence over moving inside the
> > +	 * current one, as it did when the two updates were applied in that
> > +	 * order.
> > +	 */
> 
> Comments should never refer to old code that no longer exists. Comments
> are for the code as it is now. If you want to expand on details of the
> transition from one implementation to the next, that's what the
> Changelog is for.
> 
Sorry, I'll remove the "as it did when..." part and keep the comment to the current behavior only.

Thanks
Jianyong
> > +	if (m_a_n_occ > 2 * curr_m_a_n_occ)
> > +		new_cpu = m_a_n_cpu;
> > +	else if (pref_llc_cpu >= 0 && pref_llc_occ > 2 * curr_m_a_occ)
> > +		new_cpu = pref_llc_cpu;
> > +
> > +	if (new_cpu >= 0)
> > +		WRITE_ONCE(mm->sc_stat.cpu, new_cpu);
> >
> >  	update_avg_scale(&mm->sc_stat.nr_running_avg, nr_running);
> >  	free_cpumask_var(cpus);
> > --
> > 2.34.1
> >
> >