]> git.kaiwu.me - haproxy.git/commit
BUG/MINOR: threads: properly set the number of tgroups when non using policy
authorWilly Tarreau <w@1wt.eu>
Wed, 15 Apr 2026 15:33:04 +0000 (17:33 +0200)
committerWilly Tarreau <w@1wt.eu>
Wed, 15 Apr 2026 15:47:26 +0000 (17:47 +0200)
commitd7c747b5721175d4db3865f354b87def8cc5cb70
tree31b7b48d43bc622850de1e563581feeb72341381
parent794737cc8dea6cbdcdfafee62c68e9df2ec07f6d
BUG/MINOR: threads: properly set the number of tgroups when non using policy

When nbthread is set, the CPU policies are not used and do not set
nbthread nor nbtgroups. When back into thread_detect_count(), these
are set respectively to thr_max and 1. The problem which becomes very
visible with max-threads-per-group, is that setting this one in
combination with nbthreads results in only one group with the calculated
number of threads per group. And there's not even a warning. So basically
a configuration having:

   global
       nbthread 64
       max-threads-per-group 8

would only start 8 threads.

In this case, grp_min remains valid and should be used, so let's just
change the assignment so that the number of groups is always correct.

A few ifdefs had to move because the calculations were only made for
the USE_CPU_AFFINITY case. Now these parts have been refined so that
all the logic continues to apply even without USE_CPU_AFFINITY.

One visible side effect is that setting nbthread above 64 will
automatically create the associated number of groups even when
USE_CPU_AFFINITY is not set. Previously it was silently changed
to match the per-group limit.

Ideally this should be backported to 3.2 where the issue was
introduced, though it may change the behavior of configs that were
silently being ignored (e.g. "nbthread 128"), so the backport should
be considered with care. At least 3.3 should have it because it uses
cpu-policy by default so it's only for failing cases that it would be
involved.
src/thread.c