userspace-rcu/fix-only-wait-if-work-queue-is-empty-in-real-time-mo.patch

49 lines
1.7 KiB
Diff
Raw Normal View History

2019-09-30 11:19:12 -04:00
From 803e59362b6d94edff3a36f47a9da3e8dca4bde2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9mie=20Galarneau?=
<jeremie.galarneau@efficios.com>
Date: Fri, 7 Dec 2018 17:06:39 -0500
Subject: [PATCH 10/15] Fix: only wait if work queue is empty in real-time mode
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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>
---
src/workqueue.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/workqueue.c b/src/workqueue.c
index 39d0e07..14957a0 100644
--- 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);
--
2.19.1