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.
There may be other trade-offs that I am not aware of. Hence, this
is submitted as "RFC".
Signed-off-by: Jérémie Galarneau <jeremie.galarn...@efficios.com>
---
src/workqueue.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/workqueue.c b/src/workqueue.c
index 6822314..d81e381 100644
--- a/src/workqueue.c
+++ b/src/workqueue.c
@@ -248,7 +248,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);
--
2.19.2
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
