tree b7c1cd3e2c1dab8c8ba4f04a29264f2172cc0c2f
parent a48f51b96547cfe9119b3762d91cb0a01f3b1c10
author Willy Tarreau <w@1wt.eu> 1676534820 +0100
committer Christopher Faulet <cfaulet@haproxy.com> 1682088679 +0200

BUG/MINOR: sched: properly report long_rq when tasks remain in the queue

There's a per-thread "long_rq" counter that is used to indicate how
often we leave the scheduler with tasks still present in the run queue.
The purpose is to know when tune.runqueue-depth served to limit latency,
due to a large number of tasks being runnable at once.

However there's a bug there, it's not always set: if after the first
run, one heavy task was processed and later only heavy tasks remain,
we'll loop back to not_done_yet where we try to pick more tasks, but
none are eligible (since heavy ones have already run) so we directly
return without incrementing the counter. This is what causes ultra-low
values on long_rq during massive SSL handshakes, that are confusing
because they make one believe that tl_class_mask doesn't have the HEAVY
flag anymore. Let's just fix that by not returning from the middle of
the function.

This can be backported as far as 2.4.

(cherry picked from commit 2e270cf0b0824fb2b83f2ee737a75272687ba9c4)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 31d3ddb23eea3523604c02f9cec8948bbe425829)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit c38d665d0480b08c7c553a6e6ecb80afae0463e2)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit d74896af481c53b7551901144215f4e0399456d3)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>