Date: Fri, 6 Mar 2015 23:23:35 -0700 From: Warner Losh <imp@bsdimp.com> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: Andriy Gapon <avg@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: RFC: Simplfying hyperthreading distinctions Message-ID: <6E129CCC-C4CD-45A4-9945-3384A20B7A31@bsdimp.com> In-Reply-To: <54FA5EE9.4090305@freebsd.org> References: <1640664.8z9mx3EOQs@ralph.baldwin.cx> <54FA5EE9.4090305@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_83014606-E21B-4976-A8FC-F6259E09C50F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> On Mar 6, 2015, at 7:14 PM, Nathan Whitehorn <nwhitehorn@freebsd.org> =
wrote:
>=20
>=20
> On 03/06/15 12:44, John Baldwin wrote:
>> Currently we go out of our way a bit to distinguish Pentium4-era
>> hyperthreading from more recent ("modern") hyperthreading. I suspect =
that
>> this distinction probably results in confusion more than anything =
else.
>> Intel's documentation does not make near as broad a distinction as =
far as I
>> can tell. Both types of SMT are called hyperthreading in the SDM for =
example.
>> However, we have the astonishing behavior that
>> 'machdep.hyperthreading_allowed' only affects "old" hyperthreads, but =
not
>> "new" ones. We also try to be overly cute in our dmesg output by =
using HTT
>> for "old" hyperthreading, and SMT for "new" hyperthreading. I =
propose the
>> following changes to simplify things a bit:
>>=20
>> 1) Call both "old" and "new" hyperthreading HTT in dmesg.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> What do people think?
>=20
> I'm fine with whatever naming, but if we're making new sysctls, =
especially for the cpuset case, is there a reason to hide the behavior =
under machdep? We support at least three non-x86 CPUs with SMT (POWER8, =
Cell, and POWER5) and the relevant scheduling logic should be MI. At =
least POWER8 supports 8 threads per core, so you might also want more =
granularity than just "on" or "off=E2=80=9D.
MIPS has xlr/xlp support as well, which has threads=E2=80=A6
Warner
--Apple-Mail=_83014606-E21B-4976-A8FC-F6259E09C50F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJU+plnAAoJEGwc0Sh9sBEAawYQAL5g/isuGc8rbJMuWNj2YV8Z
ct1YjZPshrrh9ZSV6ApPbeROi07Ki7d3z1SzhJ2njUBaZHj/gCNHUqEIZnW3FSll
W0nx25kKNUs3opmW5CTXz0HkNgzvbXjz2zbBH7HF4fJuPlx4UF79pPSl0a+00lzO
DoTypj+qhEtTGGAmnJcU+3XDojXTpLOZwIAgIJLworAuAog6SEa7Uj5pUvESDWPz
ODCu04eNndTkwX/X/PkAXhunYrim24zJjjh6s+aFsyVVbQ7YdiAcbWzDNy+NBWbD
6CkjD0NkaCTlzyPVGC1Ha/kRVi+o4josZBPqpuiHd/1Z6zZc23R2j0NtdMxFa4Xq
0K6/SCmZiouDUy+kzh8xuA757ve94Ci5l/i15OEl+tDyDMiqnK/hZTnlrD6gBLEg
A058xjnjamyw3lOE60rm6up3ox8JTMZj9dxkZ5mXj/WCIs9huISPuWw7MM9qtK4Z
Kh3gfwVWBEl2BjTJLlpCOGEBkiqB21j9pyGjU6hfUMmlv6BPG8wAMWg/xEKyKfNg
I8lLMw1MRP1EyqOBcwYXbg7nJk41akVkJ+gUuv2mX8NGBX7fgR8FQtZBZMwBWc7n
lS070L6Zhew1/9xUGf9Y5XThrrqO8L8vd+onX4vAdH5GJi9ppfcBcijJPNGYBAaf
dCENqrYpUNBHhE2me4qE
=uUW+
-----END PGP SIGNATURE-----
--Apple-Mail=_83014606-E21B-4976-A8FC-F6259E09C50F--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6E129CCC-C4CD-45A4-9945-3384A20B7A31>