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

[Valentin Schneider]

On 12/05/26 17:55, Shrikanth Hegde wrote:
> 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.

Yeah you're right, let's forget about it for now :-)