Re: [PATCH v3 13/21] sched/cache: Handle moving single tasks to/from their preferred LLC

[Peter Zijlstra]

On Tue, Feb 10, 2026 at 02:18:53PM -0800, Tim Chen wrote:
> In the generic load balance(non-cache-aware-load-balance),
> if the busiest runqueue has only one task, active balancing may be
> invoked to move it. However, this migration might break LLC locality.

I'm thinking this wants more explanation; yes it might break locality,
but why is that bad?

This way you're inhibiting a full LLC from being able to power down.

> +/*
> + * Check if active load balance breaks LLC locality in
> + * terms of cache aware load balance.
> + */
> +static inline bool
> +alb_break_llc(struct lb_env *env)
> +{
> +	if (!sched_cache_enabled())
> +		return false;
> +
> +	if (cpus_share_cache(env->src_cpu, env->dst_cpu))
> +		return false;
> +	/*
> +	 * All tasks prefer to stay on their current CPU.
> +	 * Do not pull a task from its preferred CPU if:
> +	 * 1. It is the only task running there; OR
> +	 * 2. Migrating it away from its preferred LLC would violate
> +	 *    the cache-aware scheduling policy.
> +	 */
> +	if (env->src_rq->nr_pref_llc_running &&
> +	    env->src_rq->nr_pref_llc_running == env->src_rq->cfs.h_nr_runnable) {
> +		unsigned long util = 0;
> +		struct task_struct *cur;
> +
> +		if (env->src_rq->nr_running <= 1)
> +			return true;
> +
> +		/*
> +		 * Reach here in load balance with
> +		 * rcu_read_lock() protected.
> +		 */

Not sure that comment helps much. rcu_dereference() itself will already
cause complaints if the constraints are violated.

> +		cur = rcu_dereference(env->src_rq->curr);
> +		if (cur)
> +			util = task_util(cur);
> +
> +		if (can_migrate_llc(env->src_cpu, env->dst_cpu,
> +				    util, false) == mig_forbid)
> +			return true;
> +	}
> +
> +	return false;
> +}