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

[Chen, Yu C]

Hi Xusheng,

On 7/27/2026 2:41 PM, Zhan Xusheng wrote:
> On Mon, Jul 27, 2026 at 09:29:14AM +0800, Chen Yu wrote:
> > -	if (sched_asym(env->sd, i, env->dst_cpu) && nr_running == 1)
> > +	if (sched_asym(env->sd, i, env->dst_cpu) && nr_running == 1 &&
> > +	    env->migration_type != migrate_llc_task)
> >   		continue;
>
> The fix looks correct for the ITMT case. I also convinced myself it does
> not introduce a migrate_llc_task <-> asym-packing ping-pong: once the task
> lands in its preferred LLC, a subsequent asym pull-back is a migrate_task,
> which goes through can_migrate_task() -> migrate_degrades_llc() ->
> can_migrate_llc_task() == mig_forbid (moving away from the preferred LLC),
> so it returns 0 and the task is not pulled back (modulo the
> nr_balance_failed >= cache_nice_tries + 1 escape). So it should not
> oscillate. Nice.

Thanks for checking the ping-pong angle, and I agree it does not oscillate.
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.

> One minor consistency question: the adjacent single-task filter just above,
>
> 	if (env->sd->flags & SD_ASYM_CPUCAPACITY &&
> 	    !capacity_greater(capacity_of(env->dst_cpu), capacity) &&
> 	    nr_running == 1)
> 		continue;
>
> has the same nr_running == 1 shape and is not exempted for
> migrate_llc_task. I don't think it is reachable on current hardware (it
> would need both multiple LLCs, so migrate_llc_task can fire, and
> asymmetric CPU capacity at that domain), so this is not a correctness
> concern for the reported case. But since the two filters now treat
> migrate_llc_task differently, was leaving the capacity one intentional
> (capacity prioritized over cache locality on asym-capacity), or just out
> of scope here? A word in the changelog would make the intent clear.

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. In theory the priority follows the
order of enum group_type: the priority of group_llc_balance is lower than
that of group_overloaded and higher than that of all other group types.

thanks,
Chenyu