linux-kernel - Re: [PATCH 10/19] sched/fair: Prioritize tasks preferring destination LLC during 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANCG0GdR-0Yh16nuAWq477RyWXhzbo_ppDsH9hQrbkxRqw1+-g@mail.gmail.com>
Date: Wed, 29 Oct 2025 05:51:32 -0400
From: Aaron Lu <ziqianlu@...edance.com>
To: "Chen, Yu C" <yu.c.chen@...el.com>
Cc: Tim Chen <tim.c.chen@...ux.intel.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>, 
	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>, 
	Libo Chen <libo.chen@...cle.com>, Adam Li <adamli@...amperecomputing.com>, 
	Tim Chen <tim.c.chen@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/19] sched/fair: Prioritize tasks preferring destination
 LLC during balancing

On Mon, Oct 27, 2025 at 10:00:52AM +0800, Chen, Yu C wrote:
> Hi Aaron,
>
> On 10/24/2025 5:32 PM, Aaron Lu wrote:
> > Hi Tim,
> >
> > On Sat, Oct 11, 2025 at 11:24:47AM -0700, Tim Chen wrote:
> > > @@ -10849,11 +10849,45 @@ static void record_sg_llc_stats(struct lb_env *env,
> > >   	if (unlikely(READ_ONCE(sd_share->capacity) != sgs->group_capacity))
> > >   		WRITE_ONCE(sd_share->capacity, sgs->group_capacity);
> > >   }
> > > +
> > > +/*
> > > + * Do LLC balance on sched group that contains LLC, and have tasks preferring
> > > + * to run on LLC in idle dst_cpu.
> > > + */
> > > +static inline bool llc_balance(struct lb_env *env, struct sg_lb_stats *sgs,
> > > +			       struct sched_group *group)
> > > +{
> > > +	struct sched_domain *child = env->sd->child;
> > > +	int llc;
> > > +
> > > +	if (!sched_cache_enabled())
> > > +		return false;
> > > +
> > > +	if (env->sd->flags & SD_SHARE_LLC)
> > > +		return false;
> > > +
> > > +	/* only care about task migration among LLCs */
> > > +	if (child && !(child->flags & SD_SHARE_LLC))
> > > +		return false;
> > > +
> > > +	llc = llc_idx(env->dst_cpu);
> > > +	if (sgs->nr_pref_llc[llc] > 0 &&
> > > +	    can_migrate_llc(env->src_cpu, env->dst_cpu, 0, true) == mig_llc)
> >
> > llc_balance() is called from update_sg_lb_stats() and at that time,
> > env->src_cpu is not determined yet so should not be used here?
> >
>
> You are right, I think we should check the candidate group's first
> CPU rather than the env->src_cpu. Will fix it in the next version.

Looks like can_migrate_llc() doesn't care an exact cpu but any cpu in the
same LLC should do, so either the candidate group's first cpu or any
other cpus in that group should make no difference.

It might be more intuitive to prototype can_migrate_llc() with sd_shared
as param than using cpu, just a thought.