DOC: config: fix a few typos and refine cpu-affinity

There were two typos in the recently updated parts about per-group.
Also, change the commas to ':' after the options values, as sometimes
it would be confusing. Last, place quotes around keyword names so that
they're explicitly referred to as language keywords. No backport is
needed.
This commit is contained in:
Willy Tarreau
2026-01-07 09:19:25 +01:00
parent 83457b9e38
commit c3fcdfaf5c

View File

@@ -2230,26 +2230,25 @@ cpu-map [auto:]<thread-group>[/<thread-set>] <cpu-set>[,...] [...]
cpu-affinity <affinity>
Defines how you want threads to be bound to cpus.
It currently accepts the following values :
- per-core, each thread will be bound to all the hardware threads of one core.
- per-group, each thread will be bound to all the hardware threads of the
group. This is the default unless threads-per-core 1 is used in cpu-policy.
per-group accepts an optional argument, to specify how CPUs should be
allocated. When a list of CPUs is larger than the maximum allozed number
of CPUs per group and has to be split between multiple groups, an extra
option allows to choose how the groups will be bound to those CPUs:
- per-core: each thread will be bound to all the hardware threads of one core.
- per-group: each thread will be bound to all the hardware threads of the
group. This is the default unless "threads-per-core 1" is used in
"cpu-policy". "per-group" accepts an optional argument, to specify how CPUs
should be allocated. When a list of CPUs is larger than the maximum allowed
number of CPUs per group and has to be split between multiple groups, an
extra option allows to choose how the groups will be bound to those CPUs:
- auto: each thread group will only be assigned a fair share of contiguous
CPU cores that are dedicated to it and not shared with other groups.
This is the default as it generally is more optimal.
be shared across two thread groups. This is the default.
CPU cores that are dedicated to it and not shared with other groups. This
is the default as it generally is more optimal.
- loose: each group will still be allowed to use any CPU in the list. This
generally causes more contention, but may sometimes help deal better
with parasitic loads running on the same CPUs.
- auto, per-group will be used, unless threads-per-core 1 is used in
cpu-policy, in which case per-core will be used. This is the default.
- per-thread, that will bind one thread to one hardware thread only.
If threads-per-core 1 is used in cpu-policy, then each thread will be bound
to one hardware thread of a different core.
- per-ccx, each thread will be bound to all the hardware threads of a CCX.
generally causes more contention, but may sometimes help deal better with
parasitic loads running on the same CPUs.
- auto: "per-group" will be used, unless "threads-per-core 1" is used in
"cpu-policy", in which case "per-core" will be used. This is the default.
- per-thread: that will bind one thread to one hardware thread only. If
"threads-per-core 1" is used in "cpu-policy", then each thread will be
bound to one hardware thread of a different core.
- per-ccx: each thread will be bound to all the hardware threads of a CCX.
cpu-policy <policy> [threads-per-core 1 | auto]
Selects the CPU allocation policy to be used.