50 lines
1.6 KiB
Diff
50 lines
1.6 KiB
Diff
|
From 79eca0929fc50a668a15937b5bf4d1cb97049de8 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:38 -0500
|
||
|
|
Subject: [PATCH 09/15] Fix: don't wait after completion of a work queue job
|
||
|
|
batch
|
||
|
|
MIME-Version: 1.0
|
||
|
|
Content-Type: text/plain; charset=UTF-8
|
||
|
|
Content-Transfer-Encoding: 8bit
|
||
|
|
|
||
|
|
As indicated in the previous patch of this series, waiting on
|
||
|
|
completion of a job batch from the work queue artificially increases
|
||
|
|
the latency of the work queue.
|
||
|
|
|
||
|
|
The previous patch removed the wait that is performed when the
|
||
|
|
work queue is observed to be empty and was observed as the cause of a
|
||
|
|
performance problem.
|
||
|
|
|
||
|
|
It is likely that waiting when the queue is observed to be non-empty
|
||
|
|
is similarly unintended. Note that I have not observed such a problem
|
||
|
|
myself.
|
||
|
|
|
||
|
|
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 | 2 --
|
||
|
|
1 file changed, 2 deletions(-)
|
||
|
|
|
||
|
|
diff --git a/src/workqueue.c b/src/workqueue.c
|
||
|
|
index 0b1a9ea..39d0e07 100644
|
||
|
|
--- a/src/workqueue.c
|
||
|
|
+++ b/src/workqueue.c
|
||
|
|
@@ -244,8 +244,6 @@ static void *workqueue_thread(void *arg)
|
||
|
|
* urcu_work list.
|
||
|
|
*/
|
||
|
|
cmm_smp_mb();
|
||
|
|
- } else {
|
||
|
|
- (void) poll(NULL, 0, 10);
|
||
|
|
}
|
||
|
|
} else {
|
||
|
|
(void) poll(NULL, 0, 10);
|
||
|
|
--
|
||
|
|
2.19.1
|
||
|
|
|