Hi Lukas!

On Thu, Oct 15, 2020 at 12:53:33AM +0200, Lukas Tribus wrote:
> Hello,
> 
> On Wed, 14 Oct 2020 at 15:29, Willy Tarreau <w...@1wt.eu> wrote:
> > For "nbproc", given that I had no response in the previous question and
> > I anticipate some surprises if I play games with it, I'll probably apply
> > William's suggestion, consisting in starting to emit a warning about it,
> > and asking users to either remove it, or explicitly mention "nbthread 1"
> > to get rid of the warning, and to report their use case.
> 
> What about multi-threading performance across NUMA nodes?

There is no reason to share the exact same conf across NUMA nodes. If
you see them as independent machines (their own CPU, RAM and NIC) then
it remains perfectly possible (and desirable) to have completely separate
process, handed as independent services so that you can maintain them
separately.

> On discourse someone asked why nbproc and nbthread can't be combined:
> 
> https://discourse.haproxy.org/t/cpu-affinity-nbproc-1-and-nbthread-1/5675

Thanks for the link!

We had that in 1.8 and it was a total mess. I wanted to stop that very
quickly seeing that it was impossible when reading a config to know what
was coherent and what was not. When you realize that in your config, only
*some* parts will be synchronized via peers and others not, that some
backend servers will be seen as up in some threads belonging to a process
and down in others, stats will differ, CLI will only affect a process at
a time etc, and all this each time with multiple threads together. I'd
say that it combines all the defects of each mode!

> I'm not sure if this is a real use-case or simply a case of overengineering 
> ...

There will always be one "valid" use case here and there, but quite frankly
if you don't purposely share data, frontends or backends between CPU groups,
there will be little difference because nowadays a *lot* of stuff is thread
local. The scheduler is both local and global, fdtab is lockless, etc. I'd
rather get reports from those experiencing limitations when this happens,
we maintain LTS versions long enough to allow them to run something that
suits their needs for the time needed to address such issues. Plus given
that these people will not be QUIC users, they'll have limited interest in
upgrading to the latest versions.

By the way, I'd be curious to know what makes some people think they *need*
40 CPUs, beyond the common belief "I paid those cores, I need to use them
all".

Thanks!
Willy

Reply via email to