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.