summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorPaul E. McKenney <paulmck@linux.vnet.ibm.com>2013-04-18 14:25:03 -0700
committerPaul E. McKenney <paulmck@linux.vnet.ibm.com>2013-08-18 17:05:32 -0700
commitd84297c99bd9f63baf92c9f2d36582f879858664 (patch)
tree5fa42b0c2ef8ae93f016dd5b0ea318bc720f5482
parentf7f7bac9cb1c50783f15937a11743655a5756a36 (diff)
downloadop-kernel-dev-d84297c99bd9f63baf92c9f2d36582f879858664.zip
op-kernel-dev-d84297c99bd9f63baf92c9f2d36582f879858664.tar.gz
rcu: Fix rcu_barrier() documentation
There was a time when rcu_barrier() was guaranteed to wait for at least a grace period, but that time ended due to energy-efficiency concerns. So now rcu_barrier() is a no-op if there are no RCU callbacks queued in the system. This commit updates the documentation to reflect this change. Now, rcu_barrier() often does wait for a grace period, so, one could imagine some modification to rcu_barrier() to more efficiently handle cases where both rcu_barrier() and a grace period are needed. But this must wait until someone shows a real-world need for a change. Reported-by: Bob Copeland <bob@cozybit.com> Reported-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org>
-rw-r--r--Documentation/RCU/rcubarrier.txt12
1 files changed, 8 insertions, 4 deletions
diff --git a/Documentation/RCU/rcubarrier.txt b/Documentation/RCU/rcubarrier.txt
index 2e319d1..b10cfe7 100644
--- a/Documentation/RCU/rcubarrier.txt
+++ b/Documentation/RCU/rcubarrier.txt
@@ -70,10 +70,14 @@ in realtime kernels in order to avoid excessive scheduling latencies.
rcu_barrier()
-We instead need the rcu_barrier() primitive. This primitive is similar
-to synchronize_rcu(), but instead of waiting solely for a grace
-period to elapse, it also waits for all outstanding RCU callbacks to
-complete. Pseudo-code using rcu_barrier() is as follows:
+We instead need the rcu_barrier() primitive. Rather than waiting for
+a grace period to elapse, rcu_barrier() waits for all outstanding RCU
+callbacks to complete. Please note that rcu_barrier() does -not- imply
+synchronize_rcu(), in particular, if there are no RCU callbacks queued
+anywhere, rcu_barrier() is within its rights to return immediately,
+without waiting for a grace period to elapse.
+
+Pseudo-code using rcu_barrier() is as follows:
1. Prevent any new RCU callbacks from being posted.
2. Execute rcu_barrier().
OpenPOWER on IntegriCloud