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

[Jianyong Wu <wujianyong@hygon.cn>]

Hi Peter,

> -----Original Message-----
> From: Peter Zijlstra <peterz@infradead.org>
> Sent: Monday, August 31, 2026 9:17 PM
> To: Jianyong Wu <wujianyong@hygon.cn>
> Cc: Ingo Molnar <mingo@redhat.com>; Juri Lelli <juri.lelli@redhat.com>;
> Vincent Guittot <vincent.guittot@linaro.org>; Chen Yu
> <yu.c.chen@intel.com>; Tim Chen <tim.c.chen@linux.intel.com>; Dietmar
> Eggemann <dietmar.eggemann@arm.com>; Steven Rostedt
> <rostedt@goodmis.org>; Ben Segall <bsegall@google.com>; Mel Gorman
> <mgorman@suse.de>; Valentin Schneider <vschneid@redhat.com>; K
> Prateek Nayak <kprateek.nayak@amd.com>; Shrikanth Hegde
> <sshegde@linux.ibm.com>; Phil Auld <pauld@redhat.com>; Andrew
> Morton <akpm@linux-foundation.org>; David Hildenbrand
> <david@kernel.org>; linux-kernel@vger.kernel.org; linux-mm@kvack.org;
> jianyong.wu@outlook.com; Yuan Zhong <zhongyuan@hygon.cn>; Huangsj
> <huangsj@hygon.cn>; Fengyu Wang <wangfengyu@hygon.cn>; Zhiwei Ying
> <yingzhiwei@hygon.cn>; justin.he@arm.com
> 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
> >
> >