BUG/MINOR: init: properly detect NUMA bindings on large systems
authorWilly Tarreau <w@1wt.eu>
Thu, 9 Mar 2023 09:12:06 +0000 (10:12 +0100)
committerWilly Tarreau <w@1wt.eu>
Thu, 9 Mar 2023 09:17:37 +0000 (10:17 +0100)
commitf5b63277f416376b54276d4f0f9ea7999525180e
tree429c8384ebd48c8de47a9498a0bbfac809b332b0
parentbe795ceb91b158b325db11ecac01cc3c4c73afe9
BUG/MINOR: init: properly detect NUMA bindings on large systems

The NUMA detection code tries not to interfer with any taskset the user
could have specified in init scripts. For this it compares the number of
CPUs available with the number the process is bound to. However, the CPU
count is retrieved after being applied an upper bound of MAX_THREADS, so
if the machine has more than 64 CPUs, the comparison always fails and
makes haproxy think the user has already enforced a binding, and it does
not pin it anymore to a single NUMA node.

This can be verified by issuing:

  $ socat /path/to/sock - <<< "show info" | grep thread

On a dual 48-CPU machine it reports 64, implying that threads are allowed
to run on the second socket:

  Nbthread: 64

With this fix, the function properly reports 96, and the output shows 48,
indicating that a single NUMA node was used:

  Nbthread: 48

Of course nothing is changed when "no numa-cpu-mapping" is specified:

  Nbthread: 64

This can be backported to 2.4.
src/thread.c