Re: [PATCH] sched/cache: honor migrate_llc_task semantics in active load balance
From: Chen, Yu C
Date: Mon Aug 03 2026 - 00:21:31 EST
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