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

[Lu Wang <wanglu.priv@gmail.com>]

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"

If (a), the per-task check is needed.

Happy to discuss further.