Re: [PATCH v3 04/21] sched/cache: Make LLC id continuous

[Chen, Yu C]

On 2/19/2026 11:48 PM, Peter Zijlstra wrote:
> On Tue, Feb 17, 2026 at 01:39:45PM +0530, K Prateek Nayak wrote:
> > I'm not sure if this is technically possible but assume following
> > topology:
> >
> >     [                 LLC: 8-15                 ]
> >     [ SMT: 8,9 ][ SMT: 10,11 ] ... [ SMT: 14,15 ]
> >
> > and the following series of events:
> >
> > o All CPUs in LLC are offline to begin with (maxcpus = 1 like scenario).
> >
> > o CPUs 10-15 are onlined first.
> >
> > o CPU8 is put in a separate root partition and brought online.
> >    (XXX: I'm not 100% sure if this is possible in this order)
> >
> > o build_sched_domains() will bail out at SMT domain since the cpumap
> >    is covered by tl->mask() and tl_llc = tl_smt.
> >
> > o llc_id calculation uses the tl_smt->mask() which will not contain
> >    CPUs 10-15 and CPU8 will get a unique LLC id even though there are
> >    other online CPUs in the LLC with a different llc_id (!!!)
>
> Yeah, so partitions (including isol_cpus) could wreck things here, since
> this is purely about the sched_domains.
>
> You can create N single CPU partitions (isol_cpus does this) and end up
> with the same 'problem' that online one at a time loop did. Except this
> time it would not be 'wrong'. Since they are single CPU domains, you
> also don't get load-balancing, so who cares I suppose. But it will
> inflate max_lid.
>
> But suppose you create N/2 partitions (where N is the number of CPUs in
> the physical LLC), then you get many individual 'LLC's and
> load-balancing inside them. I suppose this is correct, although it does
> inflate max_lid somewhat beyond what you would normally expect.
>
> However, most of that space would be wasted, since you're not actually
> allowed to migrate to them.

Besides wasting space, after removing CPUs from all N/2 partitions and
merging them into the root partition, each CPU would still have a distinct
llc_id from the other CPUs in the same LLC domain, because we do not 
reassign
llc_id values to CPUs in current version.  This issue should be resolved by
switching to the new dynamic llc_id allocation and release method.

thanks,
Chenyu