Re: [PATCH] sched/cache: Fix a thread aggregation conflict when there is one runnable task

[Zhan Xusheng]

From: Zhan Xusheng <zhanxusheng1024@xxxxxxxxx>

On 7/27/2026 5:46 PM, Chen, Yu C wrote:
> I did a further investigation, and another reason it holds: with only one
> running task, migrate_degrades_llc() is not what keeps the task in its
> preferred LLC. In the regular load balance path can_migrate_task() already
> bails at task_on_cpu() - since that task is curr. And in the active balance
> path alb_break_llc() blocks it first:
> 
> if (env->src_rq->nr_running <= 1)
>      return true;
> 
> so the task is not pulled back either way.

Thanks, that all makes sense. I traced both guards and they hold:

 - Regular load balance: for the single running task can_migrate_task()
   returns 0 at the task_on_cpu() check, so it is never pulled back on the
   normal path (and for a non-running task the migrate_degrades_llc() ->
   can_migrate_llc_task() == mig_forbid check catches it).

 - Active balance: need_active_balance() -> alb_break_llc() returns true
   because nr_pref_llc_running == h_nr_runnable and src_rq->nr_running <= 1.
   What convinced me it is not symmetric - i.e. that the forward
   migrate_llc_task still works - is that in the forward direction the task
   does not prefer the source LLC, so nr_pref_llc_running == 0 there and
   alb_break_llc() returns false.

> Good point. OK, let me add description in changelog:
> The adjacent SD_ASYM_CPUCAPACITY filter was left unchanged. In theory
> it should have been handled in the same way, but it is not clear yet
> whether any platform has both multiple LLCs and asymmetric CPU capacity,
> so the asymmetric CPU capacity logic was not fine-tuned here and can be
> revisited once such a platform shows up.

That wording answers my question well - thanks for spelling out that
leaving the capacity filter alone is intentional pending a multi-LLC +
asym-capacity platform.

Reviewed-by: Zhan Xusheng <zhanxusheng@xxxxxxxxxx>

Thanks,
Xusheng