Re: [PATCH v2 05/23] sched/cache: Assign preferred LLC ID to processes

[Chen, Yu C]

On 12/19/2025 12:01 PM, Vern Hao wrote:
> On 2025/12/16 03:32, Tim Chen wrote:
> > On Fri, 2025-12-12 at 11:34 +0800, Vern Hao wrote:
> > > On 2025/12/4 07:07, Tim Chen wrote:
> > > > With cache-aware scheduling enabled, each task is assigned a
> > > > preferred LLC ID. This allows quick identification of the LLC domain
> > > > where the task prefers to run, similar to numa_preferred_nid in
> > > > NUMA balancing.

[snip]

> > > > +
> > > > +    if (mm->mm_sched_cpu != -1) {
> > > > +        mm_sched_llc = llc_id(mm->mm_sched_cpu);
> > > > +
> > > > +#ifdef CONFIG_NUMA_BALANCING
> > > > +        /*
> > > > +         * Don't assign preferred LLC if it
> > > > +         * conflicts with NUMA balancing.
> > > > +         */
> > > > +        if (p->numa_preferred_nid >= 0 &&
> > > I wonder if the restriction here shouldn't be so strict. In Mel Gorman's
> > > patch (e496132ebedd sched/fair: Adjust the allowed NUMA imbalance when
> > > SD_NUMA spans multiple LLCs), the value of the 'imb_numa_nr' is checked
> > > to determine if |SD_NUMA| imbalance is allowed. Could we use this same
> > > check to decide whether or not to perform a cross-numa migration?
> > If we set the preferred LLC that's in a different node other than the 
> > preferred
> > node, the preferred LLC is going to fight with NUMA balancing and bounce
> > tasks back and forth between nodes. NUMA locality is going to affect 
> > performance
> > more so we'll let NUMA preference take precedence.
>
> I might not have explained myself clearly. I’m questioning whether we 
> need to integrate an imbalance check into the 'sgs->group_type|' is 
> ’group_has_spare|' scenario,  like Mel’s patch, to refine our llc 
> migration decisions.
>
> just like this:  8 cpus in one LLC, LLC-A has 6 tasks,  LLC-B has 2 
> tasks, if LLC-A has task_a need to migrate to LLC_B, how to deal it ?

If LLC_B is the preferred LLC of task_a, and if the average utilization of
LLC_B has not reached 50%, task_a will be moved to LLC_B. If LLC_A is the
preferred LLC of task_a, then if LLC_A has not reached 50%, task_a will
not be migrated to LLC_B. There are some comments around can_migrate_llc(),
which describe the decision matrix for migration.

thanks,
Chenyu