OpenBSD 6.4 only using 1 core

G Douglas Davidson douglas at readyforgo.com
Wed Feb 20 23:25:06 UTC 2019



> On Feb 20, 2019, at 5:40 PM, Stuart Henderson <stu at spacehopper.org> wrote:
> 
> On 2019/02/20 16:52, G Douglas Davidson wrote:
>> 
>>> On Feb 20, 2019, at 11:58 AM, Stuart Henderson via Unbound-users <unbound-users at nlnetlabs.nl> wrote:
>>> 
>>> On 2019-02-19, G Douglas Davidson via Unbound-users <unbound-users at nlnetlabs.nl> wrote:
>>>>>>>> OpenBSD 6.4 and the included Unbound 1.8.1.  Intel NUC with 2 real CPUS and 2 Virtual.  Some sysctl stuff:
>>>>>>>> 
>>>>>>>> 	hw.ncpu=4
>>>>>>>> 	hw.ncpufound=4
>>>>>>>> 	hw.ncpuonline=2
>>>>>>>> 	hw.smt=0
>>>>>>>> 
>>>>>>>> "top" shows four cpus with work distributed to only two of them.
>>> 
>>> That's expected, recent OpenBSD no longer schedules to SMT (hyperthreading)
>>> "cpu"s by default, controlled by sysctl hw.smt. We don't trust SMT, plus
>>> with the current state of MP on OpenBSD for many workloads it works out
>>> faster to avoid them anyway.
>> 
>> I understand this and agree with it. In my mind though, showing two
>> cpus that are simply never going to get any worth is confusing (I’m
>> easily confused.) But, again, I get it. Those cores are there, just
>> not getting work.
>> 
>> I wonder if it make sense to turn hyperthreading off at the BIOS level
>> simply as a way to keep things clean. So, looking for a recommendation
>> here.
> 
> IIRC top was changed in -current to skip them.
> 
> I prefer disabling in BIOS if I can (it's not always possible - some
> BIOS don't give the option, though recently I've noticed some have
> started adding it back - e.g. Lenovo have done this for some ThinkPads).
> But it shouldn't matter too much which way you do it.

Makes sense. I believe I am able to with my particular box.

> 
>>>> Appreciate the reply. With so-reuseport: no, things are chugging along
>>>> nicely, although the load is not particularly evenly distributed.
>>> 
>>> That's expected.
>> 
>> Can you share anything regarding how load is distributed among
>> threads? I think the big question is, if OpenBSD does not support _LB,
>> which I believe distributes load more evenly, how do I distribute
>> load more evenly (and, do I even need to?) Running forked seems like
>> another possibility. Memory is cheap. I’m not so concerned about
>> the need for a shared cache. But that decision would be based on
>> what logic causes work in the threaded version to be shunted to a
>> particular thread. It does not seem to be round-robin. I’m just damn
>> curious how that happens!
> 
> Sorry, I'm not too sure about that - it maybe worth asking on one of
> the OpenBSD lists about how the load is distributed between sockets
> though.
> 
> I haven't heard from anyone optimizing unbound for high performance
> on OpenBSD, I'd be interested to hear what you find if you do try.
> ("resperf" is probably useful for testing if you want to try that
> - it's part of dnsperf, not packaged in 6.4 but is in -current).
> 
> If I was looking into this I would certainly want to test it with
> dnsdist forwarding to multiple independent unbound instances (i.e.
> each one bound to a different port number) as one of the
> possibilities, I suspect that may be the simplest way to get
> good balance.
> 

Oh shit, I did not even think of that! Thanks man!

--
G Douglas Davidson
douglas at readyforgo.com






More information about the Unbound-users mailing list