From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 15:57:21 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 423E81065673; Tue, 26 Jul 2011 15:57:21 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 95DFB8FC16; Tue, 26 Jul 2011 15:57:20 +0000 (UTC) Received: by wyg24 with SMTP id 24so361281wyg.13 for ; Tue, 26 Jul 2011 08:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/HvtLulwzvBW5Ye9aEN3XHQ88g4nkUUd0WLOuOFEme8=; b=gi4MycjvYqG+GEafaNisADOdIQBJfK2Q5XZbzQWsG43Cijih1I+HFVYL958QcIs4V7 qZmuFgUdjCDmIT+b8TSzYeyaN3k4COqQgSO7RHwVsF/4GYvvRC+NaOKLcLfKleftqZX3 mD25gY+rW/2yhRiDOgLaZOIfcmNLxKVkssNxU= MIME-Version: 1.0 Received: by 10.227.197.196 with SMTP id el4mr5259638wbb.103.1311694493857; Tue, 26 Jul 2011 08:34:53 -0700 (PDT) Received: by 10.227.128.12 with HTTP; Tue, 26 Jul 2011 08:34:53 -0700 (PDT) In-Reply-To: <4E2ED546.2080401@FreeBSD.org> References: <4E2ED546.2080401@FreeBSD.org> Date: Tue, 26 Jul 2011 17:34:53 +0200 Message-ID: From: Harald Servat To: Andriy Gapon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Hackers Subject: Re: HTT vs SMT in x86 SMP topology reporting X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:57:21 -0000 2011/7/26 Andriy Gapon > > 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 o= f > 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=3D%28Intel+Hyper-Threading+Technology%29 > > I understand that HTT implementation has evolved over time and there coul= d > 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 Int= el > calls > it HTT. > > Also, right now things like machdep.hyperthreading_allowed act only on ol= d > 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 clea= r > to me. > E.g. I see that for old HTT we bind interrupts only to one processing uni= t > (aka > logical processor aka hardware thread) from each hyperthreading pair. No= t > 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 fo= r > 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, =93Performance Monitoring and Intel Hyper-Threading > Technology > in Processors Based on Intel NetBurst Microarchitecture,=94 for a discuss= ion > 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@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. --=20 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?!