On Thu, Feb 17, 2022 at 07:57:30AM +0100, Vincent Bernat wrote: > ? 16 February 2022 22:15 +01, Willy Tarreau: > > > 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". > > For Debian, being a binary distribution, we cannot be flexible with the > users. In the past, we were often told we were less performant than a > source distribution because we didn't enable this or this optimization. > Also, 1% CPU increase could also translate to increased latency.
I agree. I know that the vast majority of us do not care, but I know a few places where that matters. Those who have to manage 100 LBs definitely don't want to go to 101 just because we changed an option (but arguably when performing major version upgrades, variations are larger than that in both directions). > As a comparison, we did not have memory cgroups in our kernels until the > overhead was reduced quite significantly when not using them. On our > side, we believe everyone is using Debian packages. ;-) Oh I'm not surprised! I'll work more on the runtime configuration of most of these settings, as I think the most expensive hence controversial ones are the ones which should easily support adding a runtime test. For the most sensitive parts (e.g. BUG_ON() in scheduler), that should still be addressed at build time but on a case-by-case basis. I'll come back trying to propose a better long-term solution for all this. By the way Vincent, William figured that I missed a few patches during my long backport session yesterday. I'll have to check with him if they warrant another release or if they can wait for next one. Hence no need to rush on new packages yet ;-) I'll keep you updated whatever the outcome. Cheers, Willy
