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

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

On 8/4/2026 8:10 AM, Tim Chen wrote:
> On Mon, 2026-08-03 at 18:02 +0800, Lu Wang wrote:
>> Thanks for the review, Chenyu.
>>
>> I got interested in CAS because it strikes a good balance between
>> generic CFS load balancing and strict LLC/CPU affinity.
>>
>> My understanding is that migrate_llc_task encodes the target
>> direction of the balance pass, not just "ALB was triggered by CAS".
>> alb_break_llc() only vetoes ALB when every task on src_rq prefers
>> staying put (nr_pref_llc_running == cfs.h_nr_runnable); once tasks
>> have mixed preferences it lets ALB through without checking which
>> one gets picked. active_load_balance_cpu_stop() then walks
>> src_rq->cfs_tasks in reverse and takes the first task accepted by
>> can_migrate_task() — with multiple tasks on src_rq, that's not
>> necessarily the one whose preferred_llc matches the destination.
>>
>> My patch threads migration_type through to the stopper and, only
>> for migrate_llc_task, rejects a candidate whose preferred_llc
>> doesn't match the destination LLC.
>>
>> Regarding:
>>> this helps the case where the task is the only running one on the
>>> src_cpu
>>
>> If that single task already prefers the destination LLC, my check
>> still returns true, so this case is unaffected. The disagreement is
>> really about what happens when it does not prefer the destination.
>> That comes down to how we read the semantics of migrate_llc_task:
>>
>>    (a) "migrate a task toward the destination LLC selected by
>>        calculate_imbalance()", or
>>    (b) "this ALB was triggered by CAS's LLC-balance logic, so any
>>        generally-eligible task on src_rq may be pushed"
> 
> The policy of when to break LLC preference locality whether it is in regular
> load balance or in active load balance are both encoded in
> can_migrate_llc().  Sometimes when an LLC is overloaded, you may
> want to move the task off its preferred LLC.  Moving a task off its
> preferred LLC is not always wrong. Looks like you patch
> stop that with migrate_llc_task_wrong_dst().
> There is a comment section above can_migrate_llc() to
> explain the policy details.
> 

Yes. Besides, if I understand correctly, I suppose Lu Wang was
referring to the following scenario:

src_rq has 2 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() found p2 and returns true for p2
thus moves p2 out of its preferred LLC.

Here is the reason that it might not happen IMO:

Firstly, before ALB is triggered, the generic (passive) load balance is 
triggered.
It iterates over p1 and p2 on src_rq to see if it can move any one of 
them to
dst_rq, and in most cases it succeeds in moving p1 to dst_cpu. As a 
result, ALB
will not be triggered. So the scenario Lu Wang was worried about will 
not happen.

On the other hand, even if there is only p2 running on src_cpu and it 
prefers
src_cpu (src_llc), the passive load balance will fail, and ALB will be 
triggered.
However, alb_break_llc() will return true because p2 wants to stay and 
it is the
only running task, so ALB will not be triggered neither. So the scenario 
Lu Wang
worried about will not happen.

thanks,
Chenyu