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
