tree 6e7818851dbc00df906ee894796d2e005a31e337
parent 5405c9cdf3127f74201dd6a812fc45689407fe38
author Willy Tarreau <w@1wt.eu> 1676534820 +0100
committer Willy Tarreau <w@1wt.eu> 1676646094 +0100
encoding latin1

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.