On Fri, 5 Dec 2014 12:52:45 -0600 Scott Wood <scottw...@freescale.com> wrote:
> On Fri, 2014-12-05 at 16:14 +0100, Greg Kurz wrote: > > The smt-enabled kernel parameter basically leaves unwanted cpus executing > > in firmware or wherever they happen to be. The very same applies to the > > ibm,smt-enabled DT property which is no more used by anything known. These > > are hacks that shoudn't be used in a production environment. > > > > Quoting mpe, "there are better ways for firmware to disable SMT". > Hi Scott, > Those "better ways" don't apply to Freescale chips, where the OS enables > (or not) SMT without any interaction with firmware. I don't care about > the ibm,smt-enabled property, but can we please keep the smt-enabled > boot option? > Fair enough for the firmware side, what about CPU hot(un)plug then ? > > It also has an evil side effect on the split-core feature for powernv. The > > code needs all the cpus to participate to the split mode update: it relies > > on smp_send_reschedule() to get offline ones to do so. This doesn't work > > with > > cpus that haven't come up... The consequence is a kernel hang on powernv > > when > > trying to limit the number of hw threads at boot time (e.g. smt-enabled to > > anything but 8 on POWER8). > > In that case could you disable the option only on that hardware? > The fact it breaks only powernv doesn't mean it is a powernv only issue. The smt-enabled feature is a hack because it leaves some cpus in a undefined state from a kernel POV. Moreover it drags about 80 lines of code and sits entirely in common ppc64 code. I would reverse the question then ? Why not moving smt-enabled code to freescale only ? > > This patch simply removes both the smt-enabled kernel parameter and the > > ibm,smt-enabled property for all platforms. The new default is to start > > all hw threads. That leaves /sys the only supported API to change SMT > > settings. > > How would you use /sys for this? Are you talking about CPU hotplug? > Yes. This is the safer way to offline cpus. > -Scott > Cheers. -- Greg _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
