Lines Matching refs:that
1 Please note that the "What is RCU?" LWN series is an excellent place
12 RCU is a synchronization mechanism that was added to the Linux kernel
13 during the 2.5 development effort that is optimized for read-mostly
15 getting there can sometimes be a challenge. Part of the problem is that
17 assumption that there is "one true way" to describe RCU. Instead,
18 the experience has been that different people must take different paths
33 some point. People who prefer to start with an API that they can then
41 So, start with the section that makes the most sense to you and your
44 that type of person, you have perused the source code and will therefore
54 The reason that it is safe to run the removal phase concurrently with
55 readers is the semantics of modern CPUs guarantee that readers will see
67 callback that is invoked after they finish. Only readers that are active
74 a. Remove pointers to a data structure, so that subsequent
92 typically take advantage of the fact that writes to single aligned
97 and communications cache misses that are so expensive on present-day
111 that readers are not doing any sort of synchronization operations???
137 Used by a reader to inform the reclaimer that the reader is
143 remain unreclaimed for the full duration of that critical section.
151 Used by a reader to inform the reclaimer that the reader is
152 exiting an RCU read-side critical section. Note that RCU
162 Note that synchronize_rcu() will -not- necessarily wait for
177 any that begin after synchronize_rcu() is invoked.
186 Since synchronize_rcu() is the API that must figure out when
236 pointer, which returns a value that may then be safely
237 dereferenced. Note that rcu_deference() does not actually
261 Note that the value returned by rcu_dereference() is valid
282 RCU, in particular, flagging a pointer that is subject to changing
343 b. RCU applied to networking data structures that may be subjected
368 * Create a new struct foo that is the same as the one currently
369 * pointed to by gbl_foo, except that field "a" is replaced
373 * Uses rcu_assign_pointer() to ensure that concurrent readers
376 * Uses synchronize_rcu() to ensure that any readers that might
399 * to ensure that the structure does not get deleted out
400 * from under us, and use rcu_dereference() to ensure that
434 RCU read-side critical sections that might be referencing that
469 * Create a new struct foo that is the same as the one currently
470 * pointed to by gbl_foo, except that field "a" is replaced
474 * Uses rcu_assign_pointer() to ensure that concurrent readers
477 * Uses call_rcu() to ensure that any readers that might have
507 The container_of() primitive is a macro that, given a pointer into a
518 that we are now using call_rcu() rather than synchronize_rcu():
522 function that will be invoked after the completion of all RCU
523 read-side critical sections that might be referencing that
537 One of the nice things about RCU is that it has extremely simple "toy"
538 implementations that are a good first step towards understanding the
540 presents two such "toy" implementations of RCU, one that is implemented
541 in terms of familiar locking primitives, and another that more closely
556 This section presents a "toy" RCU implementation that is based on
604 it. This means that once synchronize_rcu() exits, all RCU read-side
605 critical sections that were in progress before synchronize_rcu() was
606 called are guaranteed to have completed -- there is no way that
611 be recursively acquired. Note also that rcu_read_lock() is immune
613 that the only thing that can block rcu_read_lock() is a synchronize_rcu().
624 This section presents a "toy" RCU implementation that is based on
642 Note that rcu_read_lock() and rcu_read_unlock() do absolutely nothing.
645 And there is absolutely no way that rcu_read_lock() can possibly
657 Remember that it is illegal to block while in an RCU read-side critical
659 that it must have completed all preceding RCU read-side critical sections.
663 So, suppose that we remove a data item from its structure and then invoke
665 that there are no RCU read-side critical sections holding a reference
666 to that data item, so we can safely reclaim it.
782 Also, the presence of synchronize_rcu() means that the RCU version of
784 mechanism that never blocks, namely call_rcu() or kfree_rcu(), that can
893 However, given that there are no fewer than four families of RCU APIs
908 If so, RCU-sched is the only choice that will work for you.
919 f. Do you need read-side critical sections that are respected
922 only choice that will work for you.
926 Of course, this all assumes that you have determined that RCU is in fact
955 that of CONFIG_PREEMPT_RT, where all normal spinlocks
989 One can argue that the overhead of RCU in this
991 interrupt-disabling approach. Others might argue that
992 the overhead of RCU is merely zero, and that replacing
1016 what should be boosted. Especially given that the