From: "Chen, Yu C" <yu.c.chen@intel.com>
To: K Prateek Nayak <kprateek.nayak@amd.com>,
Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Ritesh Harjani <riteshh@linux.ibm.com>,
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
<linux-sched@vger.kernel.org>, <tim.c.chen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [BUG] sched/cache: "Make LLC id continuous" causes NULL cpumask dereference in build_sched_domains on POWER9
Date: Tue, 26 May 2026 11:14:54 +0800 [thread overview]
Message-ID: <8d14c844-b4a8-4af6-acab-2cfdd42225be@intel.com> (raw)
In-Reply-To: <75179ee2-ec20-4757-8631-79b1f304c366@amd.com>
On 5/26/2026 12:16 AM, K Prateek Nayak wrote:
> Hello Chenyu, Venkat,
>
> On 5/25/2026 9:05 PM, Chen, Yu C wrote:
>> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
>> index 3467f86fd78f..cf6c2e4190ab 100644
>> --- a/arch/powerpc/kernel/smp.c
>> +++ b/arch/powerpc/kernel/smp.c
>> @@ -1042,11 +1042,6 @@ static const struct cpumask *tl_smallcore_smt_mask(struct sched_domain_topology_
>> }
>> #endif
>>
>> -struct cpumask *cpu_coregroup_mask(int cpu)
>> -{
>> - return per_cpu(cpu_coregroup_map, cpu);
>> -}
>> -
>> static bool has_coregroup_support(void)
>> {
>> /* Coregroup identification not available on shared systems */
>> @@ -1056,6 +1051,14 @@ static bool has_coregroup_support(void)
>> return coregroup_enabled;
>> }
>>
>> +struct cpumask *cpu_coregroup_mask(int cpu)
>> +{
>> + if (!has_coregroup_support())
>> + return cpu_l2_cache_mask(cpu);
>> +> + return per_cpu(cpu_coregroup_map, cpu);
>
> Interestingly, on powerpc, the MC domain doesn't have SD_SHARE_LLC flag
> set but I believe there is still some benefit of keeping the tasks on
> the same hemisphere?
>
You are right. I guess power9 reported here does not have hemisphere and
power10 has, according to commit fb2ff9fa72e2:
"From Power10 processors onwards, each chip has 2 hemispheres"
but yes on both power9 and power10, MC domain doesn't have SD_SHARE_LLC
thus aggregating threads to 1 L2 domain might bring benefit. A side note is
that, cache aware scheduling is disabled on power for now because
power does not use the generic cacheinfo framework, thus its cache size
is returned as 0 so get_effective_llc_bytes() returns 0(for now, unless
we get the help from IBM friends to support it)
commit 7030513a0877 ("7030513a0877")
> If we are actually aiming for LLC, I think cpu_l2_cache_mask() is the
> right cpumask for all cases since tl_cache_mask() also returns that
> and the l2_cache_mask is set in all cases covered by update_mask_by_l2()
> in the same file.
>
> If consolidation on hemisphere is beneficial, then the above diff
> looks correct.
>
> Note: For has_coregroup_support(), with the above fix, the scheduler
> side llc_id will now be based on MC domain's span which seems wrong
> since it doesn't have SD_SHARE_LLC flag and might lead to other
> behavioral changes now.
>
You are right, it seems to be a bug when has_coregroup_support() is enabled.
Maybe we can always return l2 id for power?
How about this(revert previous diff):
diff --git a/arch/powerpc/include/asm/topology.h
b/arch/powerpc/include/asm/topology.h
index 66ed5fe1b718..3b3b4156f418 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -130,13 +130,15 @@ static inline int cpu_to_coregroup_id(int cpu)
#ifdef CONFIG_SMP
#include <asm/cputable.h>
+#include <asm/smp.h>
struct cpumask *cpu_coregroup_mask(int cpu);
const struct cpumask *cpu_die_mask(int cpu);
int cpu_die_id(int cpu);
+#define arch_llc_mask(cpu) cpu_l2_cache_mask(cpu)
+
#ifdef CONFIG_PPC64
-#include <asm/smp.h>
#define topology_physical_package_id(cpu) (cpu_to_chip_id(cpu))
#define topology_sibling_cpumask(cpu)
(per_cpu(cpu_sibling_map, cpu))
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index df2ceb54c970..6772eb0ce493 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -2063,12 +2063,18 @@ const struct cpumask *tl_mc_mask(struct
sched_domain_topology_level *tl, int cpu
return cpu_coregroup_mask(cpu);
}
-#define llc_mask(cpu) cpu_coregroup_mask(cpu)
+#ifndef arch_llc_mask
+#define arch_llc_mask(cpu) cpu_coregroup_mask(cpu)
+#endif
#else
-#define llc_mask(cpu) cpumask_of(cpu)
+#ifndef arch_llc_mask
+#define arch_llc_mask(cpu) cpumask_of(cpu)
+#endif
#endif
+#define llc_mask(cpu) arch_llc_mask(cpu)
+
const struct cpumask *tl_pkg_mask(struct sched_domain_topology_level
*tl, int cpu)
{
return cpu_node_mask(cpu);
thanks,
Chenyu
>> +}
>> +
>> static int __init init_big_cores(void)
>> {
>> int cpu;
>
next prev parent reply other threads:[~2026-05-26 3:15 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-25 14:07 [BUG] sched/cache: "Make LLC id continuous" causes NULL cpumask dereference in build_sched_domains on POWER9 Venkat Rao Bagalkote
2026-05-25 15:35 ` Chen, Yu C
2026-05-25 16:16 ` K Prateek Nayak
2026-05-26 3:14 ` Chen, Yu C [this message]
2026-05-26 3:14 ` Srikar Dronamraju
2026-05-26 4:08 ` Chen, Yu C
2026-05-26 4:58 ` Srikar Dronamraju
2026-05-26 5:53 ` K Prateek Nayak
2026-05-26 14:08 ` [BUG] sched/cache: "Make LLC id continuous" causes NULL cpumask Chen Yu
2026-05-27 7:01 ` Shrikanth Hegde
2026-05-27 16:05 ` Chen, Yu C
2026-05-27 18:07 ` Shrikanth Hegde
2026-05-28 4:58 ` Shrikanth Hegde
2026-05-28 9:12 ` Chen, Yu C
2026-05-28 10:26 ` Shrikanth Hegde
2026-05-28 15:54 ` Srikar Dronamraju
2026-05-28 15:58 ` Srikar Dronamraju
2026-05-27 16:30 ` K Prateek Nayak
2026-05-26 5:24 ` [BUG] sched/cache: "Make LLC id continuous" causes NULL cpumask dereference in build_sched_domains on POWER9 Venkat Rao Bagalkote
2026-05-27 7:05 ` Shrikanth Hegde
2026-05-28 16:01 ` Srikar Dronamraju
2026-05-28 6:54 ` Ritesh Harjani
2026-05-28 16:06 ` Srikar Dronamraju
2026-05-28 11:27 ` Shrikanth Hegde
2026-05-28 13:21 ` Chen, Yu C
2026-05-28 15:06 ` Ritesh Harjani
2026-05-28 15:56 ` Srikar Dronamraju
2026-05-28 16:31 ` Shrikanth Hegde
2026-05-28 16:44 ` Srikar Dronamraju
2026-05-29 3:58 ` Shrikanth Hegde
2026-05-29 6:59 ` Venkat Rao Bagalkote
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8d14c844-b4a8-4af6-acab-2cfdd42225be@intel.com \
--to=yu.c.chen@intel.com \
--cc=chleroy@kernel.org \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sched@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=peterz@infradead.org \
--cc=riteshh@linux.ibm.com \
--cc=sshegde@linux.ibm.com \
--cc=tim.c.chen@linux.intel.com \
--cc=venkat88@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox