srcu-3: add RCU variant that permits read-side blocking
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest2 patches 2 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | srcu-3: RCU variant permitting read-side blockingDocumentation/ Documentation/ Documentation/ +3 more | +331 | 2 replies | |
| 2/2 | srcu-3: add SRCU operations to rcutortureDocumentation/ kernel/ | +132 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/2] srcu-3: add RCU variant that permits read-side blocking
Version 3 of the SRCU patchset.
This patch incorporates a number of improvements, many of which came up in off-list discussions with Alan Stern. Neither of us are sure why these discussions ended up off-list, so I have summarized them below.
o Fixes some "zombie code" -- excess curly braces and the like.
o Gets rid of the double-flip in favor of an additional
synchronize_sched(). This turned out to be safe, despite my saying otherwise at http://lkml.org/lkml/2006/6/27/486.
The trick that I was missing is that synchronize_sched() forces all CPUs to execute at least one memory barrier during the synchronize_sched()'s execution, which forces all CPUs to see synchronize_srcu()'s counter increment as happening after any memory manipulations prior to the synchronize_srcu().
Upgraded comments to indicate what the synchronize_sched() calls are needed for.
o Added a barrier() to both srcu_read_lock() and srcu_read_unlock()
to prevent the compiler from performing optimizations that would cause the critical section to move outside of the enclosing srcu_read_lock() and srcu_read_unlock().
However, these barrier()s in srcu_read_lock() and srcu_read_unlock() are needed only in non-CONFIG_PREEMPT kernels, so they compile to nothing in CONFIG_PREEMPT kernels (where the preempt_disable() and preempt_enable() calls supply the needed barrier() call).
o Added a check to synchronize_srcu() that permits this primitive
to take advantage of grace periods induced by concurrent executions in other tasks. This can be useful in cases where you are using a single srcu_struct to handle all the individually-locked chains of a hash table, for example.
o cleanup_srcu_struct() now contains error checks to catch cases
where readers are still using the srcu_struct in question. It does a WARN_ON() and leaks the srcu_struct's per-CPU data in that case.
o There is an srcu_readers_active() that returns the number of
readers (approximate!) currently using the specified srcu_struct. This can be useful when terminating use of an srcu_struct, e.g., at module-unload time.
o Improved the RCU torture tests, increasing the skew on reader
times and providing implementation-specific delay functions.