From owner-freebsd-arch@FreeBSD.ORG Sun Mar 8 22:28:09 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10212AB0 for ; Sun, 8 Mar 2015 22:28:09 +0000 (UTC) Received: from mail.as41113.net (mail.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id B7967F76 for ; Sun, 8 Mar 2015 22:28:07 +0000 (UTC) Received: from [172.21.88.60] (cpc6-staf8-2-0-cust519.3-1.cable.virginm.net [82.16.54.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mail@m.jwh.me.uk) by mail.as41113.net (Postfix) with ESMTPSA id 3l0cYd3bMNz1N1yB for ; Sun, 8 Mar 2015 22:19:49 +0000 (GMT) Message-ID: <54FCCAEE.7000908@m.jwh.me.uk> Date: Sun, 08 Mar 2015 22:19:26 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: RFC: Simplfying hyperthreading distinctions References: <1640664.8z9mx3EOQs@ralph.baldwin.cx> <2092193.qt8NhEKglv@ralph.baldwin.cx> <54FAC83F.7020008@freebsd.org> In-Reply-To: <54FAC83F.7020008@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Sun, 08 Mar 2015 22:28:09 -0000 On 07/03/2015 09:43, Julian Elischer wrote: > On 3/6/15 3:41 PM, John Baldwin wrote: >> 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 like the HTT (SMT variant) idea. More information is better. Surely the solution here is having an MI term, or perhaps at least one per arch (x86, mips, et al), rather than having one per arch and then per cpu family? Especially given that it is only older CPUs that use HTT rather than SMT then it makes sense to support the majority rather than the minority... (Whilst I have only limited knowledge on the subject it seems like common sense, sorry)