OpenBSD 6.4 only using 1 core

[Stuart Henderson]

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.

> >> 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.