Fix: only wait if work queue is empty in real-time mode

Unconditionally waiting for 10 ms after the completion of every batch
of jobs of the work queue in real-time mode appears to be a behaviour
inherited from the call-rcu thread.

While this is a fair trade-off in the context of call-rcu, it is less
evident that it is desirable in the context of a general-purpose
work queue. Waiting when work is available artificially degrades the
latency characteristics of the work queue.

If a workqueue user even need the explicit delay for batching (e.g. if
a call-rcu implementation would ever use the workqueue worker thread),
it can add it within the worker_before_wait_fct callback received as
argument from workqueue creation.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

diff --git a/src/workqueue.c b/src/workqueue.c
index 39d0e077acc101b5e1588c9a1fae954050bd134c..14957a0d3910aa83740d4e22b5420aa48658cf84 100644 (file)
--- a/src/workqueue.c
+++ b/src/workqueue.c
@@ -246,7 +246,10 @@ static void *workqueue_thread(void *arg)
                                cmm_smp_mb();
                        }
                } else {
-                       (void) poll(NULL, 0, 10);
+                       if (cds_wfcq_empty(&workqueue->cbs_head,
+                                       &workqueue->cbs_tail)) {
+                               (void) poll(NULL, 0, 10);
+                       }
                }
                if (workqueue->worker_after_wake_up_fct)
                        workqueue->worker_after_wake_up_fct(workqueue, workqueue->priv);