On 09/10/21 01:37, Barry Song wrote:

On Sat, Oct 9, 2021 at 12:54 AM Valentin Schneider
[off-list ref] wrote:

quoted

Barry recently introduced a new CONFIG_SCHED_CLUSTER, and discussions
around that highlighted that every architecture redefines its own help text
and dependencies for CONFIG_SCHED_SMT and CONFIG_SCHED_MC.

Move the definition of those to scheduler's Kconfig to centralize help text
and generic dependencies (i.e. SMP). Make them depend on a matching
ARCH_SUPPORTS_SCHED_* which the architectures can select with the relevant
architecture-specific dependency.

s390 uses its own topology table (set_sched_topology()) and doesn't seem to
cope without SCHED_MC or SCHED_SMT, so those remain untogglable.

Hi Valentin,
Thanks!
I believe this is a cleaner way for Kconfig itself. But I am not quite sure this
is always beneficial of all platforms. It would be perfect if the patch has no
side effects and doesn't change the existing behaviour. But it has side effects
by changing the default N to Y on a couple of platforms.

So x86 has it default yes, and a lot of others (e.g. arm64) have it default
no.

IMO you don't gain much by disabling them. SCHED_MC and SCHED_CLUSTER only
control the presence of a sched_domain_topology_level - if it's useless it
gets degenerated at domain build time. Some valid reasons for not using
them is if the architecture defines its own topology table (e.g. powerpc
has CACHE and MC levels which are not gated behind any CONFIG).

SCHED_SMT has an impact on code generated in sched/core.c, but that is also
gated by a static key.

So I'd say having them default yes is sensible. I'd even say we should
change the "If unsure say N here." to "Y".