> On Feb 20, 2019, at 11:58 AM, Stuart Henderson via Unbound-users > <[email protected]> wrote: > > On 2019-02-19, G Douglas Davidson via Unbound-users > <[email protected]> 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! —doug -- G Douglas Davidson [email protected]
