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

["Chen, Yu C" <yu.c.chen@intel.com>]

Hi Wang,

Thanks for taking a look at cas,

On 8/1/2026 8:22 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 preserve the migration type on
> the runqueue across the asynchronous boundary.
> 
> 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.
> 

[ ... ]

>   static inline bool
>   migrate_degrades_llc(struct task_struct *p, struct lb_env *env)
>   {
> @@ -10796,7 +10813,7 @@ int can_migrate_task(struct task_struct *p, struct lb_env *env)
>   	 * 4) too many balance attempts have failed.
>   	 */
>   	if (env->flags & LBF_ACTIVE_LB)
> -		return 1;
> +		return !migrate_llc_task_wrong_dst(p, env);
>   

When checking whether active load balance is needed in 
need_active_balance(),
alb_break_llc() is called to determine if the balance would break LLC 
locality
  (i.e., prevent a task from being migrated away from its preferred 
LLC). Later
in need_active_balance(), if LLC locality is not broken and the task is of
migrate_llc_task type, we force an active load balance. This means that 
once
active load balance reaches can_migrate_task(), we want it to always 
return true
- this helps the case where the task is the only running one on the 
src_cpu. Given
this logic, I do not see the need for the duplicated LLC-locality check in
can_migrate_task() for active load balance. Am I missing anything here?

thanks,
Chenyu