Re: [PATCH 0/3] sched: Simplify ifdeffery around CONFIG_SCHED_SMT

[Shrikanth Hegde <sshegde@linux.ibm.com>]

Hi Valentin.

On 5/12/26 4:29 PM, Valentin Schneider wrote:
> On 06/05/26 16:30, Shrikanth Hegde wrote:
>> Plus, Major distros make CONFIG_SCHED_SMT=y for all major
>> archs and few archs unconditionally make CONFIG_SCHED_SMT=y (x86,
>> s390), So CONFIG_SCHED_SMT=n is a rare case.
>>
> 
> That leaves only a handful of #ifdefs:
> 
>    include/linux/sched/topology.h:35:2:#ifdef CONFIG_SCHED_SMT
>    kernel/sched/topology.c:1757:2:#ifdef CONFIG_SCHED_SMT
>    kernel/sched/topology.c:1802:2:#ifdef CONFIG_SCHED_SMT
>    arch/powerpc/kernel/smp.c:986:2:#ifdef CONFIG_SCHED_SMT
>    arch/powerpc/kernel/smp.c:1038:2:#ifdef CONFIG_SCHED_SMT
>    arch/powerpc/kernel/smp.c:1720:2:#ifdef CONFIG_SCHED_SMT
>    arch/powerpc/include/asm/smp.h:141:2:#ifdef CONFIG_SCHED_SMT
> 
> The topology code could deal with unconditionally building an SMT layer as
> it'll just get degenerated. The powerpc usage is mostly topology and
> cpu_smt_mask(). So if we want to push for it, we could even get rid of the
> config entirely.
> 

I think that's tricky. This is my take. Feel free to add/correct.

1 - That's policy decision making. It is only scheduler perspective.
     hardware topology mapping need to necessarily be on the same
     page. Hence we have the config today.


2 - Implementation is difficult as well.

Lets say we define it as:

#if !defined(cpu_smt_mask)
static inline const struct cpumask *cpu_smt_mask(int cpu)
{
         return topology_sibling_cpumask(cpu);
}
#endif

Then topology_sibling_cpumask could still point to actual HW siblings and SMT domain
may not degenerate as it could have more than 1 CPU. And Since powerpc for example
defined cpu_smt_mask, will have SMT domain always. That's not correct IMO.