Date: Sat, 21 Mar 2015 12:24:20 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Slawa Olhovchenkov <slw@zxy.spb.ru>, John Baldwin <jhb@freebsd.org> Cc: Harrison Grundy <harrison.grundy@astrodoggroup.com>, freebsd-arch@freebsd.org Subject: Re: RFC: Simplfying hyperthreading distinctions Message-ID: <550DC564.5020802@freebsd.org> In-Reply-To: <20150320123823.GA49621@zxy.spb.ru> References: <1640664.8z9mx3EOQs@ralph.baldwin.cx> <54FA1180.3080605@astrodoggroup.com> <1526311.uylCbgv5VB@ralph.baldwin.cx> <20150320123823.GA49621@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
John,
Just a quick note on this, hopefully it's not too off-topic...
We need to detect if HTT or SMT is enabled, right now there are no
sysctl nodes to detect this and instead we have to parse xml out of the
scheduler...
Does it make sense to have a basic sysctl tree for this?
hw.cpu.threading.smt=0
hw.cpu.threading.htt=0
or something?
On 3/20/15 5:38 AM, Slawa Olhovchenkov wrote:
> On Fri, Mar 06, 2015 at 04:17:37PM -0500, John Baldwin wrote:
>
>> On Friday, March 06, 2015 12:43:44 PM Harrison Grundy 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 not sure of how interrupt handling works as it relates to HTT, but
>>> wouldn't using cpuset potentially leave them active for interrupt
>>> handling?
>>>
>>> Other than that question, this all makes sense to me.
>> Interrupt handling works differently. Per my commit a few minutes ago, we do
>> not send interrupts to hyperthreads by default (either old or new). However,
>> ithreads that are not explicitly bound to a specific CPU will "float" among
>> all the CPUs in set 1 so 3) would affect that. Eventually I want to use a
>> separate cpuset for interrupts that ithreads inherit from (rather than
>> belonging to set 1).
> Can you explain interrupt handling some more?
> How routing real interrupt? Can be real interrupt routing to specific
> core?
> Is real interrupt and `cpuset -x irq` is same (I see interrup from
> chelsio on cpu other then pinned)?
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?550DC564.5020802>