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

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

Thanks, Chenyu.

On Tue, 2026-08-04 at 16:17 +0800, Chen, Yu C wrote:
> 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.

That's exactly the scenario I had in mind.

> 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.

My question is whether p1 is guaranteed to be moved out in passive
LB. can_migrate_task()/migrate_degrades_llc() can reject p1 for
several independent reasons — p1 pinned by cpus_ptr, p1 cache-hot
with nr_balance_failed still below cache_nice_tries, or
can_migrate_llc_task() returning something other than mig_forbid due
to capacity constraints on dst_llc at that instant. If passive LB
rejects p1 for any of these, ALB is still triggered with p1 and p2
both present on src_rq.

Can we conclude that p1 and p2 never end up on src_rq together when
ALB fires? Or would it help to set up a simple experiment and trace
this path to see whether it actually occurs in practice?

Wang