Fix: don't wait after completion of job batch if work queue is empty
authorJérémie Galarneau <jeremie.galarneau@efficios.com>
Fri, 7 Dec 2018 22:06:37 +0000 (17:06 -0500)
committerMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Thu, 16 Dec 2021 20:44:06 +0000 (15:44 -0500)
commit44ffe4e9acc32f3ee97c171ddd4a8ef2c04eebdf
tree68fe552d38ca9466fd1fe62811cf77b972e0fc71
parenta74e66614120ba98109a48244fab30fcce92ff83
Fix: don't wait after completion of job batch if work queue is empty

On completion of a batch of jobs from the work queue, a wait of 10
ms (using poll()) is performed if there is no work present in the
work queue before waiting on its futex.

The work queue thread's structure is inspired by the call-rcu thread.
In the context of the call-rcu thread, my understanding is that the
intention is to ensure that the thread does not continuously wake-up
to process a single queued item. This is fine as an application should
not wait for a call-rcu job to be executed (or at least I don't see a
use-case for that).

In the context of the work queue, waiting for more work to be available
artificially slows down the execution of work on which an application
may wait.

I have observed a case where LTTng's session daemon's shutdown is
takes around 4 seconds as a large number of cds_lfht objects are
destroyed. Removing the wait reduces the duration of this phase of the
shut-down to almost ~10ms.

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>
workqueue.c
This page took 0.024309 seconds and 4 git commands to generate.