diff options
author | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | 2013-04-18 14:25:03 -0700 |
---|---|---|
committer | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | 2013-08-18 17:05:32 -0700 |
commit | d84297c99bd9f63baf92c9f2d36582f879858664 (patch) | |
tree | 5fa42b0c2ef8ae93f016dd5b0ea318bc720f5482 | |
parent | f7f7bac9cb1c50783f15937a11743655a5756a36 (diff) | |
download | op-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.txt | 12 |
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(). |