From owner-freebsd-arch@FreeBSD.ORG Fri Mar 6 20:59:23 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 862AF50B; Fri, 6 Mar 2015 20:59:23 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com [17.172.220.236]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B3E3125; Fri, 6 Mar 2015 20:59:23 +0000 (UTC) Received: from [10.60.0.53] (209-23-203-214-Illinois.hfc.comcastbusiness.net [209.23.203.214]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NKT00EL66AGWU40@st11p02mm-asmtp001.mac.com>; Fri, 06 Mar 2015 20:59:06 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-03-06_06:2015-03-06,2015-03-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1503060232 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: RFC: Simplfying hyperthreading distinctions From: Rui Paulo In-reply-to: <1640664.8z9mx3EOQs@ralph.baldwin.cx> Date: Fri, 06 Mar 2015 12:59:04 -0800 Content-transfer-encoding: quoted-printable Message-id: <145BFBD8-7092-42F3-BCF3-5CBB78D15893@me.com> References: <1640664.8z9mx3EOQs@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.2070.6) 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 20:59:23 -0000 > On 6 Mar 2015, at 12:44, John Baldwin wrote: >=20 > Currently we go out of our way a bit to distinguish Pentium4-era=20 > hyperthreading from more recent ("modern") hyperthreading. I suspect = that=20 > this distinction probably results in confusion more than anything = else. =20 > Intel's documentation does not make near as broad a distinction as far = as I=20 > can tell. Both types of SMT are called hyperthreading in the SDM for = example. =20 > However, we have the astonishing behavior that=20 > 'machdep.hyperthreading_allowed' only affects "old" hyperthreads, but = not=20 > "new" ones. We also try to be overly cute in our dmesg output by = using HTT=20 > for "old" hyperthreading, and SMT for "new" hyperthreading. Yes, this is annoying. > I propose the=20 > following changes to simplify things a bit: >=20 > 1) Call both "old" and "new" hyperthreading HTT in dmesg. Yes. > 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. I think that's ok given 3). > 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. Sounds good. Thanks, -- Rui Paulo