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

Tim Chen <[email protected]> Mon, 03 Aug 2026 17:10:26 -0700
Newsgroups org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On Mon, 2026-08-03 at 18:02 +0800, Lu Wang wrote:
> Thanks for the review, Chenyu.
>=20
> I got interested in CAS because it strikes a good balance between
> generic CFS load balancing and strict LLC/CPU affinity.
>=20
> 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 =3D=3D 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() =E2=80=94 with multiple tasks on src_rq, that's not
> necessarily the one whose preferred_llc matches the destination.
>=20
> 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.
>=20
> Regarding:
> > this helps the case where the task is the only running one on the
> > src_cpu
>=20
> 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:
>=20
>   (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 regula=
r
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(). =C2=A0
There is a comment section above can_migrate_llc() to
explain the policy details.

Tim

>=20
> If (a), the per-task check is needed.
>=20
> Happy to discuss further.