Hi Vincent,

On Wed, Feb 16, 2022 at 07:08:38PM +0100, Vincent Bernat wrote:
>  ? 16 February 2022 16:27 +01, Willy Tarreau:
> > Maybe that would even be a nice improvement for distros to provide these
> > by default starting with 2.6 or maybe even 2.5.
> Why not enabling them directly on your side then? Are there some numbers
> on the performance impact of these options? I am a bit uncomfortable
> providing packages that perform slower than an upstream build.

That's exactly the sense behind the word "maybe" above, to open the
discussion :-)  Those with large buffers can definitely see a
difference. I've seen configs with WAF analysis using 1MB buffers,
and there the extra CPU usage will be noticeable, maybe 5-10%. My
impression is that the vast majority of users rely on distro packages
and are not sensitive to performance (typically sites like haproxy.org
where enabling everything has no measurable impact, when I'm lucky I
see 1% CPU). Those who deal with high levels of traffic tend to be
forced to follow stable updates more often, they'll typically build
from the Git tree, and are also more at ease with debugging options.
That was my reasoning, it may be wrong, and I perfectly understand
your point which is equally valid. And I'm not even asking for a
change, just saying "maybe it would be even better if".

What I'd like to do for 2.6 and beyond would be to have multiple levels
of protection/debugging classified by impacts. The vast majority of the
BUG_ON() we have have absolutely zero impact. Some in the past were
placed long after the code was written just to confirm that what was
understood was correct. Thus we couldn't enable them by default. Then
we started to place a lot more like plain assert() but still disabled
by default to avoid affecting performance. And due to this raising
concern about performance we don't put any into very sensitive places
where it could help for the vast majority of users. So my goal would
be to enable by default all those which have no visible impact, and
let users easily change them in case of trouble. Similarly some of the
DEBUG options will likely be enabled by default when the impact is
tiny. Nowadays for example I think we can afford to lose 8 bytes in
an allocated area to store the pointer to the last caller (especially
for free). This might possibly save one week to one month of round
trips in an issue, depending on the frequency of crashes for a given

Once we manage to establish a balanced set of protection mechanisms
and debugging options, we can better document the ones that can save
the last few percent of performance or memory consumption, and the
ones that improve the accuracy of bug reports. In this case maybe
some users will more naturally enable some of them to get more solid
reports (we all prefer to produce undisputable bug reports, as there's
nothing more irritating than a developer expressing doubts about their

The options I mentioned today do not yet have this level of granularity,
they will have an impact, albeit a small one, hence why I'd prefer to
ask on a voluntary basis only. With some of the usual reporters, this is
something that is regularly done when asked, and I think that openly
indicating the costs and benefits around this allows us to progressively
get out of a debug-centric model and start to look into the direction of
a more generally proactive model.

There will always be exceptions anyway, but finer grained control is
necessary to enable such stuff by default in its current form.


Reply via email to