Re: [PATCH v2] sched/cache: honor migrate_llc_task semantics in active load balance
From: Lu Wang
Date: Tue Aug 11 2026 - 13:09:45 EST
Hi Chenyu,
Thanks for the review and the suggestions.
On 8/11/2026 6:23 PM, Chen, Yu C wrote:
> 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.
>
>> 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.
Thanks. I will add the p1/p2 problem statement and move the rationale for
selecting the stopper callback at kick time into the commit log.
>> +/*
>> + * 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."
Thanks. I will update the helper comment accordingly.
I will include these commit-log and comment-only updates in v3.
Thanks,
Lu Wang