Lines Matching refs:side
14 tool for the job. Yes, RCU does reduce read-side overhead by
15 increasing write-side overhead, which is exactly why normal uses
24 read-side primitives is critically important.
55 2. Do the RCU read-side critical sections make proper use of
59 under your read-side code, which can greatly increase the
64 rcu_read_lock_sched(), or by the appropriate update-side lock.
68 Letting RCU-protected pointers "leak" out of an RCU read-side
72 -before- letting them out of the RCU read-side critical section.
147 perfectly legal (if redundant) for update-side code to
152 of an RCU read-side critical section. See lockdep.txt
183 be traversed by an RCU read-side critical section.
266 One way to stall the updates is to acquire the update-side
307 list_for_each_safe_rcu(), must be either within an RCU read-side
308 critical section or must be protected by appropriate update-side
309 locks. RCU read-side critical sections are delimited by
316 primitives when the update-side lock is held is that doing so
321 10. Conversely, if you are in an RCU read-side critical section,
322 and you don't hold the appropriate update-side lock, you -must-
328 all currently executing rcu_read_lock()-protected RCU read-side
332 read-side critical sections are protected by something other
374 SRCU read-side critical section (demarked by srcu_read_lock()
376 Please note that if you don't need to sleep in read-side critical
388 synchronize_srcu() waits only for SRCU read-side critical
391 is what makes sleeping read-side critical sections tolerable --
394 system than RCU would be if RCU's read-side critical sections
397 The ability to sleep in read-side critical sections does not
405 requiring SRCU's read-side deadlock immunity or low read-side
429 16. The various RCU read-side primitives do -not- necessarily contain
432 read-side critical sections. It is the responsibility of the
433 RCU update-side primitives to deal with this.
441 read-side critical section, while holding the right