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.
45 2.	Do the RCU read-side critical sections make proper use of
49 	under your read-side code, which can greatly increase the
54 	rcu_read_lock_sched(), or by the appropriate update-side lock.
131 		perfectly legal (if redundant) for update-side code to
136 		of an RCU read-side critical section.  See lockdep.txt
167 		be traversed by an RCU read-side critical section.
252 		One way to stall the updates is to acquire the update-side
293 	list_for_each_safe_rcu(), must be either within an RCU read-side
294 	critical section or must be protected by appropriate update-side
295 	locks.	RCU read-side critical sections are delimited by
302 	primitives when the update-side lock is held is that doing so
307 10.	Conversely, if you are in an RCU read-side critical section,
308 	and you don't hold the appropriate update-side lock, you -must-
314 	all currently executing rcu_read_lock()-protected RCU read-side
318 	read-side critical sections are protected by something other
362 	RCU, it -is- permissible to block in an SRCU read-side critical
365 	don't need to sleep in read-side critical sections, you should be
375 	A given synchronize_srcu() waits only for SRCU read-side critical
378 	is what makes sleeping read-side critical sections tolerable --
381 	system than RCU would be if RCU's read-side critical sections
384 	The ability to sleep in read-side critical sections does not
392 	requiring SRCU's read-side deadlock immunity or low read-side
410 16.	The various RCU read-side primitives do -not- necessarily contain
413 	read-side critical sections.  It is the responsibility of the
414 	RCU update-side primitives to deal with this.
422 		read-side critical section, while holding the right