MINOR: dynbuf: pass offer_buffers() the number of buffers instead of a threshold
authorWilly Tarreau <w@1wt.eu>
Sat, 20 Feb 2021 11:02:46 +0000 (12:02 +0100)
committerWilly Tarreau <w@1wt.eu>
Sat, 20 Feb 2021 11:38:18 +0000 (12:38 +0100)
commit4d77bbf8560b5d5b32409be131e4975811bfec28
treea2404db69f0c4f22cc13213ecc7b55070417ef35
parent90f366b59556f9e64c927286bfc8e9c06d511744
MINOR: dynbuf: pass offer_buffers() the number of buffers instead of a threshold

Historically this function would try to wake the most accurate number of
process_stream() waiters. But since the introduction of filters which could
also require buffers (e.g. for compression), things started not to be as
accurate anymore. Nowadays muxes and transport layers also use buffers, so
the runqueue size has nothing to do anymore with the number of supposed
users to come.

In addition to this, the threshold was compared to the number of free buffer
calculated as allocated minus used, but this didn't work anymore with local
pools since these counts are not updated upon alloc/free!

Let's clean this up and pass the number of released buffers instead, and
consider that each waiter successfully called counts as one buffer. This
is not rocket science and will not suddenly fix everything, but at least
it cannot be as wrong as it is today.

This could have been marked as a bug given that the current situation is
totally broken regarding this, but this probably doesn't completely fix
it, it only goes in a better direction. It is possible however that it
makes sense in the future to backport this as part of a larger series if
the situation significantly improves.
include/haproxy/channel.h
include/haproxy/dynbuf.h
src/check.c
src/dynbuf.c
src/flt_spoe.c
src/mux_fcgi.c
src/mux_h1.c
src/mux_h2.c
src/stream.c