Re: [PATCH 2 1/4] powerpc: drop the ability to tweak SMT mode at boot time

[Michael Ellerman <mpe@ellerman.id.au>]

On Wed, 2014-12-10 at 17:50 -0600, Scott Wood wrote:
> On Wed, 2014-12-10 at 13:14 +1100, Michael Ellerman wrote:
> > On Tue, 2014-12-09 at 18:14 -0600, Scott Wood wrote:
> > > What benefit is there to ignoring "scripture" here?  Going from an easy
> > > to use command line option to needing to mess around with the dts file
> > > is not a usability improvement.  If you want to make it Freescale-only,
> > > fine.  If you want to push me to fix the problems with the
> > > implementation, fine.
> > 
> > It's easy to use but it doesn't necessarily work.
> > 
> > You said in your other mail to Greg "Sometimes it's useful to ensure that the
> > second thread has never run when debugging a problem.".
> > 
> > But you don't know that, for all you know your firmware has started the thread
> > and it's busy looping somewhere. Perhaps you guys know that your firmware
> > doesn't do that, but it's still a hack.
> 
> I know that our firmware doesn't do that, and I can verify by reading
> the relevant register.

Lucky you :)

> > We end up with cpus in the present map, but we have no idea where they are or
> > what they are doing.
> 
> Can we check smt-enabled a little earlier and refrain from marking the
> secondary threads as present if smt is disabled?

We could, and that would make the semantics much saner. But it would actually
be exactly the opposite of what the folks who originally hit this bug want to
happen.

They are using it as a shortcut for cpu hotunplug, ie. they want the threads
asleep in Linux ready to be hotplugged back in.

This is why I wanted to remove it, because those are both valid expectations of
what smt-enabled=off should do, but they are mutually exclusive. Not to mention
that the current code doesn't implement either of those properly.

Anyway for now we should just ignore it on powernv. We can look at doing
something saner in general in future.

cheers