]> git.kaiwu.me - haproxy.git/commit
MEDIUM: sched: fix the default runqueue-depth
authorWilly Tarreau <w@1wt.eu>
Thu, 12 Nov 2026 16:24:32 +0000 (17:24 +0100)
committerWilly Tarreau <w@1wt.eu>
Thu, 12 Nov 2026 17:12:23 +0000 (18:12 +0100)
commitd8c2cb4bf64104b0fecf155ff4ff14e334a4e010
treec31eb974932fd4331956f7e8ce8d6579af6c2496
parent574e4240779ca3c694978a17f599bb2cf1d70962
MEDIUM: sched: fix the default runqueue-depth

The scheduler's run queue depth had been empirically limited to around
280/sqrt(nbhread) when the scheduler was shared between all threads and
the number of threads was very low (4-16), because by then it looked
like a good balance between contention and latency.

Nowadays, each thread has its own scheduler and the number of threads
has exploded, but this calculus remains in place. It causes a noticeable
scheduling overhead on large systems because the number of tasks each
scheduler handles at once can become ridiculously low (e.g. 14 for 256
threads), forcing some users to work around this by forcing the value
in the configuration.

Let's get rid of this outdated calculation and keep the fixed default
value of 280 that was once considered correct and that is still applied
to a single thread, since each scheduler continues to run on a single
thread. Nothing prevents changing the default again later but at least
now the value in defaults.h corresponds to the one we're running on by
default.
doc/configuration.txt
include/haproxy/defaults.h
src/haproxy.c