From owner-freebsd-arch@FreeBSD.ORG Fri Mar 6 23:42:25 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54BFCDFB; Fri, 6 Mar 2015 23:42:25 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2CC027A7; Fri, 6 Mar 2015 23:42:25 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 66722B918; Fri, 6 Mar 2015 18:42:23 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: RFC: Simplfying hyperthreading distinctions Date: Fri, 06 Mar 2015 18:41:48 -0500 Message-ID: <2092193.qt8NhEKglv@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <1640664.8z9mx3EOQs@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 06 Mar 2015 18:42:23 -0500 (EST) Cc: Andriy Gapon , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 23:42:25 -0000 On Friday, March 06, 2015 01:37:04 PM Adrian Chadd wrote: > Hi! > > 1) I'd rather we leave them as SMT/HTT as they're slightly different > things. Who knows if intel will re-introduce this stuff in their more > embedded CPU line at a future time, or add another threading type in > the future. Being told about the distinction is nice. > 2) I'd rather we had it more clearly defind - machdep.htt_allowed / > machdep.smt_allowed . Again, I'd rather have the distinction in case > Intel decide again to make their embedded things use old-style > threading. (The intel edison/galilleo boards use P1 style cores that > are low power, I can imagine a world where they reuse HTT for that.) I don't think Netburst is coming back. Even the Atom stuff is based on the PIII/Core line, not Netburst (and Atom CPUs that support HTT use the newer- style HTT, not Netburst). In the SDM it mostly seems to be Netburst vs everything else where the distinction is made (and it's not always made). We are now in the odd situation where we refer to a small (and shrinking) set of CPUs that support HTT as HTT and we refer to a much larger (and growing) set of CPUs that support HTT as something else. This means that if a random user wants to see if FreeBSD supports HTT they won't see that in dmesg on a modern CPU without having some sort of magic decoder ring. I also think the set of folks who actually care about the slight differences in HTT is quite small and not worth the cost of looking as if we don't support HTT on the majority of processors that support it. Note that BIOS manufacturers have gotten away with labeling the two things the same without people bringing out pitchforks, so I think having FreeBSD be consistent with that (and other OS's) is less confusing to users, not more. -- John Baldwin