BUG/MEDIUM: threads/polling: Use fd_cache_mask instead of fd_cache_num

fd_cache_num is the number of FDs in the FD cache. It is a global variable. So
it is underoptimized because we may be lead to consider there are waiting FDs
for the current thread in the FD cache while in fact all FDs are assigned to the
other threads. So, in such cases, the polling loop will be evaluated many more
times than necessary.

Instead, we now check if the thread id is set in the bitfield fd_cache_mask.

[wt: it's not exactly a bug, rather a design limitation of the thread
 which was not addressed in time for the 1.8 release. It can appear more
 often than we initially predicted, when more threads are running than
 the number of assigned CPU cores, or when certain threads spend
 milliseconds computing crypto keys while other threads spin on
 epoll_wait(0)=0]

This patch should be backported to 1.8.

diff --git a/src/haproxy.c b/src/haproxy.c
index 952733ee38b8f5d38d84a30d1986a8270536d235..45ff0fc2588d1efbd8e2938bad95481c893f09aa 100644 (file)
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -2392,7 +2392,7 @@ static void run_poll_loop()
 
                /* expire immediately if events are pending */
                exp = now_ms;
-               if (fd_cache_num)
+               if (fd_cache_mask & tid_bit)
                        activity[tid].wake_cache++;
                else if (active_tasks_mask & tid_bit)
                        activity[tid].wake_tasks++;