From 32467fef98f9a4f14be8864bc44b3551f8e34759 Mon Sep 17 00:00:00 2001 From: Christopher Faulet Date: Mon, 15 Jan 2018 12:16:34 +0100 Subject: [PATCH] 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. --- src/haproxy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/haproxy.c b/src/haproxy.c index 952733ee3..45ff0fc25 100644 --- 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++;