Re: [PATCH v2] sched/cache: honor migrate_llc_task semantics in active load balance

[Chen, Yu C]

On 8/9/2026 6:53 PM, Lu Wang wrote:
> A passive load-balance pass marks group_llc_balance as migrate_llc_task
> and queues active balance when it cannot move a task. The CPU stopper
> callback constructs a fresh lb_env, so select the stopper callback when
> queueing active balance to preserve the migration semantics across the
> asynchronous boundary.

Worthy adding a [Problem Statement] section to describe what issue this 
patch tries to fix
(with polish):
src_rq has two runnable tasks, p1 and p2. p1 prefers dst_rq (dst_llc), 
while p2 prefers
src_rq (src_llc). In this case, migrate_llc_task is set because src_rq 
has at least one task,
p1, that wants to migrate to dst_rq. In ALB, can_migrate_task() finds p2 
and returns true for
it, thus moving p2 out of its preferred LLC.

> For CAS-directed active balance, reject a candidate whose preferred LLC
> does not match the destination LLC. This keeps the fallback from moving
> a task away from its preferred LLC.
>
> Fixes: e4c9a4cb244a (\"sched/cache: Add migrate_llc_task migration type for cache-aware balancing\")
> Suggested-by: \"Chen, Yu C\" <yu.c.chen@xxxxxxxxx>
> Signed-off-by: Lu Wang <wanglu.priv@xxxxxxxxx>
> ---
> Changes in v2:
>   - Select the stopper callback at kick time to preserve
>     migrate_llc_task semantics in active load balance without passing
>     migration_type across the stopper, which affects delayed-dequeue tasks.

Maybe move the above reasoning about why the new stopper function is needed
into the commit log for future reference.

> @@ -10645,6 +10646,20 @@ alb_break_llc(struct lb_env *env)
>   	return false;
>   }
>   
> +/*
> + * Returns true if p's preferred LLC does not match the destination CPU
> + * under migrate_llc_task semantics. Passive LB passes migrate_llc_task
> + * in migration_type, while active LB carries it in LBF_ACTIVE_LB_LLC.

"while active LB carries LBF_ACTIVE_LB_LLC in env->flags to avoid 
overwriting
env->migrate_type."

Per my understanding,

Reviewed-by: Chen Yu <yu.c.chen@xxxxxxxxx>

thanks,
Chenyu