OpenBSD 6.4 only using 1 core

G Douglas Davidson douglas at
Wed Feb 20 21:52:52 UTC 2019

> On Feb 20, 2019, at 11:58 AM, Stuart Henderson via Unbound-users <unbound-users at> wrote:
> On 2019-02-19, G Douglas Davidson via Unbound-users <unbound-users at> 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.

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

>> I don't believe OpenBSD supports the _LB stuff as of now.
> Correct.

I very much appreciate the reply!


G Douglas Davidson
douglas at

More information about the Unbound-users mailing list