[PATCH v7 0/8] sched/fair: Get rid of sched_domains_curr_level hack for tl->cpumask()

[K Prateek Nayak]

Hello Shrikanth,

On 8/29/2025 2:23 PM, Shrikanth Hegde wrote:
> I was looking at: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=sched/core
> 
> Current code doesn't allow one to enable/disable SCHED_MC on ppc since it is set always in kconfig.
> Used the below patch:
> 
> I think since the config is there, it would be good to provide a option to disable. no?

I think this makes sense.

FWIW, Peter added the "select SCHED_MC" to keep it consistent with the
current behavior.

> 
> ---
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index fc0d1c19f5a1..da5b2f8d3686 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -170,9 +170,8 @@ config PPC
>      select ARCH_STACKWALK
>      select ARCH_SUPPORTS_ATOMIC_RMW
>      select ARCH_SUPPORTS_DEBUG_PAGEALLOC    if PPC_BOOK3S || PPC_8xx
> -    select ARCH_SUPPORTS_SCHED_SMT        if PPC64 && SMP
>      select ARCH_SUPPORTS_SCHED_MC        if PPC64 && SMP
> -    select SCHED_MC                if ARCH_SUPPORTS_SCHED_MC
> +    select ARCH_SUPPORTS_SCHED_SMT        if PPC64 && SMP
>      select ARCH_USE_BUILTIN_BSWAP
>      select ARCH_USE_CMPXCHG_LOCKREF        if PPC64
>      select ARCH_USE_MEMTEST
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 68edb66c2964..458ec5bd859e 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -1706,10 +1706,12 @@ static void __init build_sched_topology(void)
>              SDTL_INIT(tl_cache_mask, powerpc_shared_cache_flags, CACHE);
>      }
>  
> +#ifdef CONFIG_SCHED_MC
>      if (has_coregroup_support()) {
>          powerpc_topology[i++] =
>              SDTL_INIT(tl_mc_mask, powerpc_shared_proc_flags, MC);
>      }
> +#endif

When I was looking at this, the whole of .*coregroup.* related bits in
smp.c can technically go behind CONFIG_SCHED_MC too but that is a much
larger cleanup and perhaps unnecessary too so this looks good.

-- 
Thanks and Regards,
Prateek