> On Feb 20, 2019, at 5:40 PM, Stuart Henderson <[email protected]> wrote: > > On 2019/02/20 16:52, G Douglas Davidson wrote: >> >>> 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. > > 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 [email protected]
Re: OpenBSD 6.4 only using 1 core
G Douglas Davidson via Unbound-users Wed, 20 Feb 2019 15:26:52 -0800
- OpenBSD 6.4 only using 1 core G Douglas Davidson via Unbound-users
- Re: OpenBSD 6.4 only using 1 cor... G Douglas Davidson via Unbound-users
- Re: OpenBSD 6.4 only using 1... G Douglas Davidson via Unbound-users
- Re: OpenBSD 6.4 only usi... Wouter Wijngaards via Unbound-users
- Re: OpenBSD 6.4 only... G Douglas Davidson via Unbound-users
- Re: OpenBSD 6.4... Stuart Henderson via Unbound-users
- Re: OpenBSD... G Douglas Davidson via Unbound-users
- Re: Ope... Stuart Henderson via Unbound-users
- Re: Ope... G Douglas Davidson via Unbound-users
