Lines Matching refs:to
10 0. Is RCU being applied to a read-mostly situation? If the data
28 RCU does allow -readers- to run (almost) naked, but -writers- must
33 c. restricting updates to a single task.
35 If you choose #b, be prepared to describe how you have handled
37 them -- even x86 allows later loads to be reordered to precede
38 earlier stores), and be prepared to explain why this added
39 complexity is worthwhile. If you choose #c, be prepared to
42 information relating to itself that other tasks can read, there
47 to prevent grace periods from ending prematurely, which
60 The whole point of RCU is to permit readers to run without
63 of ways to handle this concurrency, depending on the situation:
66 primitives to add, remove, and replace elements on
68 RCU-protected data structures that have been added to
81 c. Make updates appear atomic to readers. For example,
82 pointer updates to properly aligned fields will
85 appear to be atomic to RCU readers, nor will sequences
88 This can work, but is starting to get a bit tricky.
93 given modern CPUs' tendency to reorder memory references.
96 making it difficult to understand and to test.
98 It is usually better to group the changing data into
100 to appear atomic by updating a pointer to reference
104 are weakly ordered -- even x86 CPUs allow later loads to be
105 reordered to precede earlier stores. RCU code must take all of
106 the following measures to prevent memory-corruption problems:
111 that the pointer points to. This really is necessary
123 with a bit of devious creativity, it is possible to
131 perfectly legal (if redundant) for update-side code to
134 is common to readers and updaters. However, lockdep
137 to learn what to do about this.
145 to prevent weakly ordered machines from misordering
151 primitive must be used to keep list_del()'s pointer
157 may be used to replace an old structure with a new one
160 d. Rules similar to (4b) and (4c) apply to the "hlist_nulls"
164 structure happens before pointers to that structure are
166 when publicizing a pointer to a structure that can
171 must be written to be called from softirq context. In particular,
182 and unfriendly to real-time workloads. Use of the expedited
183 primitives should be restricted to rare configuration-change
190 a single non-expedited primitive to cover the entire batch.
193 of the system, especially to real-time workloads running on
196 In addition, it is illegal to call the expedited forms from
198 by a CPU-hotplug notifier. Failing to observe this restriction
216 One exception to this rule: rcu_read_lock() and rcu_read_unlock()
218 in cases where local bottom halves are already known to be
227 should be used in preference to call_rcu(). Furthermore,
238 cases where grace periods are delayed, as failing to do so can
246 those waiting for a grace period to elapse. Enforce a
247 limit on this number, stalling updates as needed to allow
248 previously deferred frees to complete. Alternatively,
252 One way to stall the updates is to acquire the update-side
255 from ever ending.) Another way to stall the updates
256 is for the updates to use a wrapper function around
270 be necessary to automatically limit them. The theory
271 here is that superuser already has lots of ways to crash
274 d. Use call_rcu_bh() rather than call_rcu(), in order to take
281 The same cautions apply to call_rcu_bh(), call_rcu_sched(),
284 Note that although these primitives do take action to avoid memory
287 if a system with a large number of CPUs has been configured to
299 order to keep lockdep happy, in this case, rcu_dereference_bh().
301 The reason that it is permissible to use RCU list-traversal
309 use the "_rcu()" variants of the list macros. Failing to do so
310 will break Alpha, cause aggressive compilers to generate bad code,
311 and confuse people trying to read your code.
313 11. Note that synchronize_rcu() -only- guarantees to wait until
322 for rcu_read_lock(). Code that attempts to use preemption
326 If you want to wait for interrupt handlers, NMI handlers, and
328 need to use synchronize_irq() or synchronize_sched().
330 This same limitation also applies to synchronize_rcu_bh()
331 and synchronize_srcu(), as well as to the asynchronous and
338 spin_lock_bh(), etc. Failing to disable irq on a given
340 the RCU softirq handler happens to run your RCU callback while
345 is not an issue (or, more accurately, to the extent that it is
349 to safely access and/or modify that data structure.
353 but are by -no- means guaranteed to be. For example, if a given
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
367 and easier to use than is SRCU.
373 the srcu_struct is passed to srcu_read_lock(), srcu_read_unlock()
380 subsystems using SRCU. Therefore, SRCU is less prone to OOM the
382 were permitted to sleep.
384 The ability to sleep in read-side critical sections does not
390 Therefore, SRCU should be used in preference to rw_semaphore
395 Note that, rcu_assign_pointer() relates to SRCU just as it does
396 to other forms of RCU.
399 is to wait until all pre-existing readers have finished before
401 therefore critically important to -first- remove any path
407 is the caller's responsibility to guarantee that any subsequent
412 and the compiler to freely reorder code into and out of RCU
414 RCU update-side primitives to deal with this.
417 __rcu sparse checks (enabled by CONFIG_SPARSE_RCU_POINTER) to
420 CONFIG_PROVE_RCU: check that accesses to RCU-protected data
427 same object to call_rcu() (or friends) before an RCU
429 passed that same object to call_rcu() (or friends).
431 __rcu sparse checks: tag the pointer to the RCU-protected data
437 otherwise extremely difficult to spot.