urcu:stable-0.10

Last commit made on 2018-12-09
Get this branch:
git clone -b stable-0.10 https://git.launchpad.net/urcu

Branch merges

Branch information

Name:
stable-0.10
Repository:
lp:urcu

Recent commits

803e593... by Jérémie Galarneau <email address hidden> on 2018-12-07

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 <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

79eca09... by Jérémie Galarneau <email address hidden> on 2018-12-07

Fix: don't wait after completion of a work queue job batch

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 <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

d3e42be... by Jérémie Galarneau <email address hidden> on 2018-12-07

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 <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

9e19a6b... by Mathieu Desnoyers 7 hours ago

Fix: workqueue: struct urcu_work vs rcu_head mixup

The workqueue code was derived from call-rcu, and its API
expects a struct urcu_work for work items, but it internally iterates
over struct rcu_head.

This is not an issue at runtime because both structures have the
exact same layout and content, but it is a type mixup nevertheless.

Use the right type in the implementation.

Signed-off-by: Mathieu Desnoyers <email address hidden>

136211f... by Mathieu Desnoyers 7 hours ago

Cleanup: workqueue: update comments referring to call-rcu

Signed-off-by: Mathieu Desnoyers <email address hidden>

0aa1fcc... by Jérémie Galarneau <email address hidden> on 2018-12-07

Fix: mixup between URCU_WORKQUEUE_RT and URCU_CALL_RCU_RT

The work queue implementation is derived from the call-rcu thread. A
number of references seem to have been left in place when adapting the
code for its new purpose.

The URCU_CALL_RCU_RT flag is used by wake_worker_thread() while the
rest of the workqueue.c code uses URCU_WORKQUEUE_RT to determine if
the work queue was configured in real-time mode. Both flags are defined
to the same value (0x1) and the current internal user of the
work queue (lfht) never specifies any flags.

In practice, this does not cause any problem, but this mixup should
be fixed nevertheless.

Signed-off-by: Jérémie Galarneau <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

6c249cd... by Michael Jeanson <email address hidden> on 2018-11-23

test_rwlock: Add per-thread count to verbose output

Signed-off-by: Michael Jeanson <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

904e25d... by Michael Jeanson <email address hidden> on 2018-11-23

Add *.exe to gitignore for Cygwin

Signed-off-by: Michael Jeanson <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

eec2f6a... by Michael Jeanson <email address hidden> on 2018-11-23

Fix: pthread_rwlock initialization on Cygwin

On Cygwin the PTHREAD_RWLOCK_INITIALIZER macro is not
sufficient to get a properly initialized pthread_rwlock_t
struct. Use the pthread_rwlock_init function instead which
should work on all platforms.

Signed-off-by: Michael Jeanson <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

b197ce8... by Michael Jeanson <email address hidden> on 2018-11-23

Fix: compat_futex_noasync on Cygwin

The futex_noasync compat code uses a weak symbol to share state across
different shared object which is not possible on Windows with the
Portable Executable format. Use the async compat code for both cases.

Signed-off-by: Michael Jeanson <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>