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
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
per
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 gen
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
