Lines Matching +full:low +full:- +full:side
1 .. SPDX-License-Identifier: GPL-2.0
14 0. Is RCU being applied to a read-mostly situation? If the data
18 tool for the job. Yes, RCU does reduce read-side overhead by
19 increasing write-side overhead, which is exactly why normal uses
27 Yet another exception is where the low real-time latency of RCU's
28 read-side primitives is critically important.
33 counter-intuitive situation where rcu_read_lock() and
49 them -- even x86 allows later loads to be reordered to precede
59 2. Do the RCU read-side critical sections make proper use of
63 under your read-side code, which can greatly increase the
66 As a rough rule of thumb, any dereference of an RCU-protected
68 rcu_read_lock_sched(), or by the appropriate update-side lock.
74 only in non-preemptible kernels. Such code can and will break,
77 Letting RCU-protected pointers "leak" out of an RCU read-side
81 *before* letting them out of the RCU read-side critical section.
92 an RCU-protected list. Alternatively, use the other
93 RCU-protected data structures that have been added to
98 b. Proceed as in (a) above, but also maintain per-element
100 that guard per-element state. Of course, fields that
129 are weakly ordered -- even x86 CPUs allow later loads to be
131 the following measures to prevent memory-corruption problems:
151 various "_rcu()" list-traversal primitives, such
153 perfectly legal (if redundant) for update-side code to
154 use rcu_dereference() and the "_rcu()" list-traversal
158 of an RCU read-side critical section. See lockdep.rst
162 list-traversal primitives can substitute for a good
180 in their respective types of RCU-protected lists.
183 type of RCU-protected linked lists.
189 be traversed by an RCU read-side critical section.
203 as the non-expedited forms, but expediting is both expensive and
205 to real-time workloads. Use of the expedited primitives should
206 be restricted to rare configuration-change operations that would
207 not normally be undertaken while a real-time workload is running.
208 However, real-time workloads can use rcupdate.rcu_normal kernel
215 a single non-expedited primitive to cover the entire batch.
218 of the system, especially to real-time workloads running on
222 is RCU-sched for PREEMPTION=n and RCU-preempt for PREEMPTION=y.
226 and re-enables softirq, for example, rcu_read_lock_bh() and
228 and re-enables preemption, for example, rcu_read_lock_sched() and
232 srcu_struct. The rules for the expedited RCU grace-period-wait
233 primitives are the same as for their non-expedited counterparts.
246 when using non-obvious pairs of primitives, commenting is
247 of course a must. One example of non-obvious pairing is
249 network-driver NAPI (softirq) context. BPF relies heavily on RCU
262 synchronize_rcu() without synchronize_rcu()'s multi-millisecond
264 forget" memory-freeing capabilities where it applies.
267 primitive is that it automatically self-limits: if grace periods
274 Ways of gaining this self-limiting property when using call_rcu()
277 a. Keeping a count of the number of data-structure elements
278 used by the RCU-protected data structure, including
285 One way to stall the updates is to acquire the update-side
286 mutex. (Don't try this with a spinlock -- other CPUs
301 c. Trusted update -- if updates can only be done manually by
320 9. All RCU list-traversal primitives, which include
322 list_for_each_safe_rcu(), must be either within an RCU read-side
323 critical section or must be protected by appropriate update-side
324 locks. RCU read-side critical sections are delimited by
330 The reason that it is permissible to use RCU list-traversal
331 primitives when the update-side lock is held is that doing so
340 and the read-side markers (rcu_read_lock() and rcu_read_unlock(),
343 10. Conversely, if you are in an RCU read-side critical section,
344 and you don't hold the appropriate update-side lock, you *must*
359 an issue, the memory-allocator locking handles it). However,
368 surviving CPU. (If this was not the case, a self-spawning RCU
372 for some real-time workloads, this is the whole point of using
376 SRCU read-side critical section (demarked by srcu_read_lock()
378 Please note that if you don't need to sleep in read-side critical
390 synchronize_srcu() waits only for SRCU read-side critical
393 is what makes sleeping read-side critical sections tolerable --
396 system than RCU would be if RCU's read-side critical sections
399 The ability to sleep in read-side critical sections does not
402 Second, grace-period-detection overhead is amortized only
406 only in extremely read-intensive situations, or in situations
407 requiring SRCU's read-side deadlock immunity or low read-side
413 real-time workloads than is synchronize_rcu_expedited().
420 is to wait until all pre-existing readers have finished before
421 carrying out some otherwise-destructive operation. It is
427 Because these primitives only wait for pre-existing readers, it
431 15. The various RCU read-side primitives do *not* necessarily contain
434 read-side critical sections. It is the responsibility of the
435 RCU update-side primitives to deal with this.
445 check that accesses to RCU-protected data
447 read-side critical section, while holding the right
458 tag the pointer to the RCU-protected data
478 - call_rcu() -> rcu_barrier()
479 - call_srcu() -> srcu_barrier()
487 all pre-existing call_rcu() callbacks, you will need to execute