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
[-- Attachment #1 --]
> On Mar 6, 2015, at 7:14 PM, Nathan Whitehorn <nwhitehorn@freebsd.org> wrote:
>
>
> 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:
>>
>> 1) Call both "old" and "new" hyperthreading HTT in dmesg.
>>
>> 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.
>>
>> 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.
>>
>> What do people think?
>
> 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”.
MIPS has xlr/xlp support as well, which has threads…
Warner
[-- Attachment #2 --]
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6E129CCC-C4CD-45A4-9945-3384A20B7A31>