RFC: Simplfying hyperthreading distinctions

[Harrison Grundy]

On 03/06/15 12:44, John Baldwin wrote:
> Currently we go out of our way a bit to distinguish Pentium4-era 
> hyperthreading from more recent ("modern") hyperthreading.  I
> suspect that this distinction probably results in confusion more
> than anything else. Intel's documentation does not make near as
> broad a distinction as far as I can tell.  Both types of SMT are
> called hyperthreading in the SDM for example. However, we have the
> astonishing behavior that 'machdep.hyperthreading_allowed' only
> affects "old" hyperthreads, but not "new" ones.  We also try to be
> overly cute in our dmesg output by using HTT for "old"
> hyperthreading, and SMT for "new" hyperthreading.  I propose the 
> following changes to simplify things a bit:
> 
> 1) Call both "old" and "new" hyperthreading HTT in dmesg.
> 
> 2) Change machdep.hyperthreading_allowed to apply to both new and
> old HTT. However, doing this means a POLA violation in that we
> would now disable modern HTT by default.  Balanced against
> re-enabling "old" HTT by default on an increasingly-shrinking pool
> of old hardware, I think the better approach here would be to also
> change the default to allow HTT.
> 
> 3) Possibly add a different knob (or change the behavior of 
> machdep.hyperthreading_allowed) to still bring up hyperthreads, but
> leave them out of the default cpuset (set 1).  This would allow
> those threads to be re-enabled dynamically at runtime by adjusting
> the mask on set 1. The original htt settings back when
> 'hyperthreading_allowed' was introduced actually permitted this via
> by adjusting 'machdep.hlt_cpus' at runtime.
> 
> What do people think?
> 

I'm not sure of how interrupt handling works as it relates to HTT, but
wouldn't using cpuset potentially leave them active for interrupt
handling?

Other than that question, this all makes sense to me.

--- Harrison