HTT vs SMT in x86 SMP topology reporting

Harald Servat redcrash at gmail.com
Tue Jul 26 15:57:21 UTC 2011


2011/7/26 Andriy Gapon <avg at freebsd.org>

>
> Can anybody explain to me why our _x86_ SMP topology discovery and
> reporting code
> sometimes reports "HTT" and sometimes "SMT"?
> As in
>  FreeBSD/SMP: %d package(s) x %d core(s) x %d HTT threads
> vs
>  FreeBSD/SMP: %d package(s) x %d core(s) x %d SMT threads
>
> As I understand, and quoting Wikipedia (I know, I know), SMT stands for
> simultaneous multithreading and is a generic term for a particular kind of
> hardware multithreading:
> http://en.wikipedia.org/wiki/Simultaneous_multithreading
>
> The only known (to me) implementation of SMT for x86 is Intel's
> Hyper-Threading
> Technology aka HTT aka HT Technology aka hyperthreading:
> http://en.wikipedia.org/wiki/Hyper-threading
>
> http://software.intel.com/en-us/articles/intel-hyper-threading-technology-your-questions-answered/?wapkw=%28Intel+Hyper-Threading+Technology%29
>
> I understand that HTT implementation has evolved over time and there could
> be some
> reasons to distinguish HTT as implemented in e.g. Pentium 4 from HTT as
> implemented in the recent architectures like Nehalem and Sandy Bridge.
>
> But I still do not understand why we have to call the latter SMT when Intel
> calls
> it HTT.
>
> Also, right now things like machdep.hyperthreading_allowed act only on old
> hyperthreads (what we report as "HTT") but completely ignore the new ones
> (what we
> report as "SMT").  I am not sure that this is correct either...
> Perhaps there are no good reasons to disable HTT on modern CPUs, but the
> current
> behavior can definitely be confusing.
>
> In the end I would like to propose that we always report Intel HTT as HTT.
> Or even drop HTT/SMT from "x %d threads" altogether.
>
> Whether we should internally distinguish old HTT from new HTT is not clear
> to me.
> E.g. I see that for old HTT we bind interrupts only to one processing unit
> (aka
> logical processor aka hardware thread) from each hyperthreading pair.  Not
> sure if
> new HTT is so much better that we shouldn't be doing the same for it.
>
> P.S. Also currently distinction between old/new HTT technologies is made
> based on
> availability of CPUID leaf 0xB.  Not sure if this is entirely accurate for
> e.g.
> Atom processors, which we seem to detect as old HTT.
>
> A lengthy quote from volume 3A as an illustration:
> 8.7.7
> Performance Monitoring Counters
> Performance counters and their companion control MSRs are shared between
> the
> logical processors within a processor core for processors based on Intel
> NetBurst
> microarchitecture. As a result, software must manage the use of these
> resources.
> The performance counter interrupts, events, and precise event monitoring
> support
> can be set up and allocated on a per thread (per logical processor) basis.
> See Section 19.19, “Performance Monitoring and Intel Hyper-Threading
> Technology
> in Processors Based on Intel NetBurst Microarchitecture,” for a discussion
> of
> performance monitoring in the Intel Xeon processor MP.
> In Intel Atom processor family that support Intel Hyper-Threading
> Technology, the
> performance counters (general-purpose and fixed-function counters) and
> their
> companion control MSRs are duplicated for each logical processor.
>
> --
> Andriy Gapon
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>


Andriy,

  regarding the nomenclature, IIRC, the IBM Power5 processors already had
SMT back in 2004. However, I don't know if FreeBSD supports (or plans to
support) this microprocessor. Whatever the name (or the string chosen) it
looks that a single name should be given instead two in order to simplify
things.

With best regards.
-- 
 Fry: You can see how I lived before I met you.
 Bender: You lived before you met me?!
 Fry: Yeah, lots of people did.
 Bender: Really?!


More information about the freebsd-hackers mailing list