diff options
author | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | 2014-03-14 16:37:08 -0700 |
---|---|---|
committer | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | 2014-03-20 17:12:25 -0700 |
commit | 765a3f4fed708ae429ee095914a7897acb3a65bd (patch) | |
tree | 1a33b4e0e88cdebf60855f6c3b102819ed6986b0 /scripts/Makefile.help | |
parent | f5604f67fe8cbd6f2088b20b9463f721aa613d4b (diff) | |
download | op-kernel-dev-765a3f4fed708ae429ee095914a7897acb3a65bd.zip op-kernel-dev-765a3f4fed708ae429ee095914a7897acb3a65bd.tar.gz |
rcu: Provide grace-period piggybacking API
The following pattern is currently not well supported by RCU:
1. Make data element inaccessible to RCU readers.
2. Do work that probably lasts for more than one grace period.
3. Do something to make sure RCU readers in flight before #1 above
have completed.
Here are some things that could currently be done:
a. Do a synchronize_rcu() unconditionally at either #1 or #3 above.
This works, but imposes needless work and latency.
b. Post an RCU callback at #1 above that does a wakeup, then
wait for the wakeup at #3. This works well, but likely results
in an extra unneeded grace period. Open-coding this is also
a bit more semi-tricky code than would be good.
This commit therefore adds get_state_synchronize_rcu() and
cond_synchronize_rcu() APIs. Call get_state_synchronize_rcu() at #1
above and pass its return value to cond_synchronize_rcu() at #3 above.
This results in a call to synchronize_rcu() if no grace period has
elapsed between #1 and #3, but requires only a load, comparison, and
memory barrier if a full grace period did elapse.
Requested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Diffstat (limited to 'scripts/Makefile.help')
0 files changed, 0 insertions, 0 deletions