Re: [PATCH v2 3/3] sched/fair: Add compile time check in fastpaths for CONFIG_SCHED_SMT=n

[K Prateek Nayak <kprateek.nayak@amd.com>]

Hello Shrikanth,

On 5/13/2026 12:09 PM, Shrikanth Hegde wrote:
> 
> Hi Prateek.
> 
>> ... I think the if() above can simply check for sched_smt_active()
>> before calling is_core_idle() like:
>>
>>      if (sched_smt_active() &&
>>          !(env->sd->flags & SD_SHARE_CPUCAPACITY) &&
>>          !is_core_idle(cpu)) {
>>          ...
>>      }
>>
>> That way, we ensure we don't call is_core_idle() and the cpumask_and()
>> unnecessarily on topologies that don't have SMT domain similar to how
>> sched_use_asym_prio() guards the call to is_core_idle().
>>
>> Thoughts?
>>
> In addition, Do you think it makes sense to consolidate use of
> sched_smt_present always using sched_smt_active() ?
> 
> 
> static __always_inline bool sched_smt_active(void)
> {
>         return static_branch_likely(&sched_smt_present);
> }
> 
> kernel/sched/core_sched.c:      if (!static_branch_likely(&sched_smt_present))
> kernel/sched/fair.c:    if (!static_branch_likely(&sched_smt_present) ||
> kernel/sched/sched.h:   if (static_branch_unlikely(&sched_smt_present))
> 
> 
> The last being differing with unlikely in update_idle_core.
> Does it make sense to call sched_smt_active there as well?

I think using sched_smt_active() everywhere should be fine.

I'm not sure what made update_idle_core() special; Perhaps there was
a greater chance of running it on systems with CONFIG_SCHED_SMT
enabled but doesn't physically have SMT.

This came from commit 1b568f0aabf2 ("sched/core: Optimize SCHED_SMT")
in 2016 when SMT was perhaps not so common and sched_smt_active()
came later in 2018 with the spectre mitigation optimizations on x86
where SMT was more prevalent so it defaulted to likely.

I'll let Peter comment if he prefers keeping this branch unlikely
but from my side, unifying eveything under sched_smt_active() looks
better.

-- 
Thanks and Regards,
Prateek