Lines Matching full:side
18 tool for the job. Yes, RCU does reduce read-side overhead by
19 increasing write-side overhead, which is exactly why normal uses
28 read-side primitives is critically important.
59 2. Do the RCU read-side critical sections make proper use of
63 under your read-side code, which can greatly increase the
68 rcu_read_lock_sched(), or by the appropriate update-side lock.
77 Letting RCU-protected pointers "leak" out of an RCU read-side
81 *before* letting them out of the RCU read-side critical section.
158 perfectly legal (if redundant) for update-side code to
163 of an RCU read-side critical section. See lockdep.rst
194 be traversed by an RCU read-side critical section.
296 One way to stall the updates is to acquire the update-side
336 list_for_each_safe_rcu(), must be either within an RCU read-side
337 critical section or must be protected by appropriate update-side
338 locks. RCU read-side critical sections are delimited by
345 primitives when the update-side lock is held is that doing so
354 and the read-side markers (rcu_read_lock() and rcu_read_unlock(),
357 10. Conversely, if you are in an RCU read-side critical section,
358 and you don't hold the appropriate update-side lock, you *must*
400 SRCU read-side critical section (demarked by srcu_read_lock()
402 Please note that if you don't need to sleep in read-side critical
414 synchronize_srcu() waits only for SRCU read-side critical
417 is what makes sleeping read-side critical sections tolerable --
420 system than RCU would be if RCU's read-side critical sections
423 The ability to sleep in read-side critical sections does not
431 requiring SRCU's read-side deadlock immunity or low read-side
439 It is also permissible to sleep in RCU Tasks Trace read-side
461 15. The various RCU read-side primitives do *not* necessarily contain
464 read-side critical sections. It is the responsibility of the
465 RCU update-side primitives to deal with this.
476 are carried out under the proper RCU read-side critical