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

[Tim Chen]

On Mon, 2026-07-27 at 20:39 +0800, Zhan Xusheng wrote:
> 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.

My understanding is that SD_ASYM_CPUCAPACITY is mostly used in the hybrid
CPU situations (e.g. P-core and E-core on some Intel client CPUs). For
those, the difference in CPU performance is pretty significant and we
likely will not get as much performance back from cache co-location vs the
CPU capacity. So I think we can leave the SD_ASYM_CPUCAPACITY code as is
till we come across a workload and platform that shows otherwise.

Otherwise,

Reviewed-by: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>

Tim

> 
> Reviewed-by: Zhan Xusheng <zhanxusheng@xxxxxxxxxx>
> 
> Thanks,
> Xusheng