Re: [PATCH v2 4/4] sched/rt: Split cpupri_vec->cpumask to per NUMA node to reduce contention

[K Prateek Nayak <kprateek.nayak@amd.com>]

Hello Chenyu, Tim,

On 4/10/2026 11:21 AM, Chen, Yu C wrote:
>>> I think per-LLC mask (or, as Tim suggested, 64CPUs per cacheline) is
>>> a good tradeoff between the speedup vs amount of loads required to
>>> piece together the full cpumask. Thoughts?
> 
> Yes, making it per LLC should work well enough (for balancing) to
> achieve optimal benefit. Let me run some similar tests to yours,plus
> hackbench/schbench, to see what the results are.
> BTW, on AMD systems, does the TILE domain always match the CCX where
> L3 is shared? On Intel the DIE is not always mapped to a domain
> where L3 is shared.

On AMD platforms that support the extended leaf 0x80000026, CCX is
always mapped to L3 and matched the data on 0x8000001D cache property
leaf for L3.

> 
>>
>> I agree that per-LLC mask is a good compromise between minimizing loads
>> and offer good speed ups.  I think we should get the LLC APICID
>> mask from 0x4 leaf (L1, L2, L3) instead of inferring from 0x1f leaf (Tile, Die ...etc)
>> for Intel.  And the cache leaf I think is 0x8000_001D leaf for AMD.
>> Those are parsed in cacheinfo code and we can get it from there.
>>
> 
> Yes, let me check how we can leverage the l3 id for that.

Ack! I think the cacheinfo is better for all this and is also compatible
with older systems that may nit have the extend topology enumeration
leaf. AMD only got it two generations ago and until that only cache
property leaf was used for marking the LLC (CCX) boundary.

-- 
Thanks and Regards,
Prateek