On 2023-01-24 23:04:14, Olivier Houchard wrote: > On Tue, Jan 24, 2023 at 11:05:37PM +0100, Willy Tarreau wrote: > > On Tue, Jan 24, 2023 at 02:15:08PM -0600, Marc West wrote: > > > > Stupid question but I prefer to ask in order to be certain, are all of > > > > these 32 threads located on the same physical CPU ? I just want to be > > > > sure that locks (kernel or user) are not traveling between multiple CPU > > > > sockets, as that ruins scalability. > > > > > > Very good observation. This is a 2 socket system, 20 cores per socket, > > > and since there is no affinity in OpenBSD unfortunately the 32 threads > > > are not on the same physical CPU. > > > > Ah, then that's particularly bad. When you're saying "there is no > > affinity", do you mean the OS doesn't implement anything or only that > > haproxy doesn't support it ? Could you please check if you have man > > pages about "cpuset_setaffinity" or "sched_setaffinity" ? The former > > is the FreeBSD version and the second the Linux version. > > Unfortunately, having a quick look at OpenBSD's sources, I don't think > they provide anything that could look like that. In fact, I'm not sure > there is any way to restrict a process to a specific CPU.
Unfortunately that is what I found also, no references to affinity in manpages nor finding any tools like taskset or NUMA related knobs. It seems to be a design decision. https://marc.info/?l=openbsd-misc&m=152507006602422&w=2 https://marc.info/?l=openbsd-tech&m=133909957708933&w=2 https://marc.info/?l=openbsd-misc&m=135884346431916&w=2 I thought there might be a way to enable just the CPUs that are on the first package via the kernel config mechanism but attempting that resulted in an immediate reboot. It looks like some kernel hacking would be needed to do this. There are no options in the BIOS to disable one of the sockets unfortunately and I don't have any single-socket machines to test with (aside from a laptop). Gven that I think we are going to have to plan to switch OS to FreeBSD for now. OpenBSD is a great OS and a joy to work with but for this particular use case we do need to handle much more HTTPS traffic in production. Thanks again for all the replies and I will have this hardware available for the foreseeable future in case there is any more testing that would be helpful.
