Re: [patch V2 01/12] sched/smt: Update sched_smt_present at runtime

[Thomas Gleixner <tglx@linutronix.de>]

On Mon, 11 Jun 2018, speck for Konrad Rzeszutek Wilk wrote:
> > +#ifdef CONFIG_SCHED_SMT
> > +	/*
> > +	 * We can't rely on the sched domains themselves to reliably inform us
> > +	 * of SMT, but if we ever see a CPU with siblings pass by, enable the
> > +	 * SMT code.
> > +	 *
> > +	 * The failure case for domains is when we boot with SMT disabled, then
> > +	 * create partitions that split all cores and then hotplug the
> 
> Don't you nee to first hotplug the siblings, then create the partitions?
> 
> Or did you mean 'hotplug' == smp_callin?

The sched domains are rebuilt when a CPU is plugged. It's done in the
scheduler hotplug function which is called on the upcoming CPU.

The current code has the following issue:

When you boot a machine with maxcpus=1, then the scheduler init code will
not see a sibling and not enable the static key.

When you plug a sibling CPU later on, then the domain rebuild will create
the proper SMT aware domains, but the static key stays false. As a
consequence SMT scheduling wont work correctly.

That's why the scheduler hotplug function needs to fiddle with the static
key as well.

Thanks,

	tglx