Hello Shrikanth,
On 5/27/2026 12:31 PM, Shrikanth Hegde wrote:
> Hi Chen, Prateek.
>
> I got back to work today, sorry for delay.
> I am trying to go through the mails.
> Apologies in case i have missed any bits.
>
> On 5/26/26 7:38 PM, Chen Yu wrote:
>> Hi Prateek,
>>
>> On Tue, 26 May 2026 11:23:59 +0530, K Prateek Nayak <[email protected]>
>> wrote:
>>> Hello Srikar,
>>>
>>> On 5/26/2026 10:28 AM, Srikar Dronamraju wrote:
>>>> L2 Cache reported here is for SMT8 Core aka CACHE domain.
>>>
>>> Apart for the scheduler, nothing in tree currently cares about
>>> cpu_coregroup_mask() except for drivers/base/arch_topology.c but
>>> Power doesn't select GENERIC_ARCH_TOPOLOGY.
>>>
>>> Why can't Power have an internal mask for MC domain (tl_mc_mask) and
>>> the scheduler can use cpu_coregroup_mask() for the actual LLc? (The L2
>>> mask in this case.)
>
> This seems wrong. there is no notion that coregroup_mask
> (MC domain) has to point at LLC domain.
It seems that only PowerPC is special at that. Only 3 architectures
override the default topology via set_sched_topology() - x86, and
s390 both still have SD_SHARE_LLC set for their MC domain, as is the
case with default_topology[] in topology.c with cpu_core_flags().
> For example, on Shared LPAR, there is no MC domain and LLC is at SMT core
> level.
> In that case coregroup_mask has point at SMT mask is wrong.
That is equivalent of MC degenerating onto the core domain right?
cpu_coregroup_mask() pointing to a core shouldn't be problematic
in that case.
> If we need a mask to point to the LLC mask which arch has to return, then we
> would
> need a new api say cpu_llc_mask ? that can point accordingly.
>
> I don't like mixing MC domain and LLC into one bit.
The SCHED_CACHE bits assume cpu_coregroup_mask() points to the sd_llc
domain and uses the sched_cpu_activate() path to assign the llc_id
independent of partitions and sched domain bits.
That assumption holds true for everything except powerpc. Is there
anything aside from the scheduler bits that use the
cpu_coregroup_mask()? We can always keep a big fat comment on top that
reads it points to the sd_llc domain and it may not be the MC domain
on power.
>> I suppose what you suggested looks like below:
Hello Chenyu! Yes, this was pretty much what I had in mind! Thank you
for the patch.
>>
>> powerpc/smp: make cpu_coregroup_mask() return the LLC
>>
>> On pSeries shared LPARs(or coregroup_enabled is false on
>> Power9 and earlier) the hemisphere map is not allocated, so
>> build_sched_domains() dereferences a NULL cpumask and crashes.
>>
>> The generic scheduler expects cpu_coregroup_mask() to span the LLC.
>> On powerpc the LLC is the L2. Return cpu_l2_cache_mask() instead of
>> the hemisphere map. Use a coregroup_map() helper for the in-file
>> hemisphere users, and a powerpc_tl_mc_mask() wrapper for the MC
>> sched-domain level.
>>
>> Fixes: b5ea300a17e3 ("sched/cache: Make LLC id continuous")
>> Reported-by: Venkat Rao Bagalkote <[email protected]>
>> Suggested-by: K Prateek Nayak <[email protected]>
>> ---
>> arch/powerpc/kernel/smp.c | 35 +++++++++++++++++++++++------------
>> 1 file changed, 23 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
>> --- a/arch/powerpc/kernel/smp.c
>> +++ b/arch/powerpc/kernel/smp.c
>> @@ -1040,11 +1040,22 @@ static const struct cpumask
>> *tl_smallcore_smt_mask(struct sched_domain_topology_
>> }
>> #endif
>> +static inline struct cpumask *coregroup_map(int cpu)
>> +{
>> + return per_cpu(cpu_coregroup_map, cpu);
>> +}
>> +
>> struct cpumask *cpu_coregroup_mask(int cpu)
>> {
>> - return per_cpu(cpu_coregroup_map, cpu);
>> + return cpu_l2_cache_mask(cpu);
>> +}
>
> This looks wrong to me too. In different hardware topologies
> there maybe distinction between coregroup and l2 mask.
>
> Let me go through the code and see if there is better way.
The other option was to add an arch_llc_mask macro that can be
optionally defined on the arch/ side if the cpu_coregroup_mask()
doesn't point to the LLC
https://lore.kernel.org/lkml/[email protected]/
--
Thanks and Regards,
Prateek
