Skip to content

Commit 7c0be9f

Browse files
neilbrownpaulmckrcu
authored andcommitted
doc: Add refcount analogy to What is RCU
The reader-writer-lock analogy is a useful way to think about RCU, but it is not always applicable. It is useful to have other analogies to work with, and particularly to emphasise that no single analogy is perfect. This patch add a "RCU as reference count" to the "what is RCU" document. See https://lwn.net/Articles/872559/ [ paulmck: Apply Akira Yokosawa feedback. ] Reviewed-by: Akira Yokosawa <akiyks@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
1 parent db4cb76 commit 7c0be9f

1 file changed

Lines changed: 82 additions & 8 deletions

File tree

Documentation/RCU/whatisRCU.rst

Lines changed: 82 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -39,9 +39,11 @@ different paths, as follows:
3939

4040
:ref:`6. ANALOGY WITH READER-WRITER LOCKING <6_whatisRCU>`
4141

42-
:ref:`7. FULL LIST OF RCU APIs <7_whatisRCU>`
42+
:ref:`7. ANALOGY WITH REFERENCE COUNTING <7_whatisRCU>`
4343

44-
:ref:`8. ANSWERS TO QUICK QUIZZES <8_whatisRCU>`
44+
:ref:`8. FULL LIST OF RCU APIs <8_whatisRCU>`
45+
46+
:ref:`9. ANSWERS TO QUICK QUIZZES <9_whatisRCU>`
4547

4648
People who prefer starting with a conceptual overview should focus on
4749
Section 1, though most readers will profit by reading this section at
@@ -677,7 +679,7 @@ Quick Quiz #1:
677679
occur when using this algorithm in a real-world Linux
678680
kernel? How could this deadlock be avoided?
679681

680-
:ref:`Answers to Quick Quiz <8_whatisRCU>`
682+
:ref:`Answers to Quick Quiz <9_whatisRCU>`
681683

682684
5B. "TOY" EXAMPLE #2: CLASSIC RCU
683685
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -732,7 +734,7 @@ Quick Quiz #2:
732734
Give an example where Classic RCU's read-side
733735
overhead is **negative**.
734736

735-
:ref:`Answers to Quick Quiz <8_whatisRCU>`
737+
:ref:`Answers to Quick Quiz <9_whatisRCU>`
736738

737739
.. _quiz_3:
738740

@@ -741,7 +743,7 @@ Quick Quiz #3:
741743
critical section, what the heck do you do in
742744
CONFIG_PREEMPT_RT, where normal spinlocks can block???
743745

744-
:ref:`Answers to Quick Quiz <8_whatisRCU>`
746+
:ref:`Answers to Quick Quiz <9_whatisRCU>`
745747

746748
.. _6_whatisRCU:
747749

@@ -872,7 +874,79 @@ be used in place of synchronize_rcu().
872874

873875
.. _7_whatisRCU:
874876

875-
7. FULL LIST OF RCU APIs
877+
7. ANALOGY WITH REFERENCE COUNTING
878+
-----------------------------------
879+
880+
The reader-writer analogy (illustrated by the previous section) is not
881+
always the best way to think about using RCU. Another helpful analogy
882+
considers RCU an effective reference count on everything which is
883+
protected by RCU.
884+
885+
A reference count typically does not prevent the referenced object's
886+
values from changing, but does prevent changes to type -- particularly the
887+
gross change of type that happens when that object's memory is freed and
888+
re-allocated for some other purpose. Once a type-safe reference to the
889+
object is obtained, some other mechanism is needed to ensure consistent
890+
access to the data in the object. This could involve taking a spinlock,
891+
but with RCU the typical approach is to perform reads with SMP-aware
892+
operations such as smp_load_acquire(), to perform updates with atomic
893+
read-modify-write operations, and to provide the necessary ordering.
894+
RCU provides a number of support functions that embed the required
895+
operations and ordering, such as the list_for_each_entry_rcu() macro
896+
used in the previous section.
897+
898+
A more focused view of the reference counting behavior is that,
899+
between rcu_read_lock() and rcu_read_unlock(), any reference taken with
900+
rcu_dereference() on a pointer marked as ``__rcu`` can be treated as
901+
though a reference-count on that object has been temporarily increased.
902+
This prevents the object from changing type. Exactly what this means
903+
will depend on normal expectations of objects of that type, but it
904+
typically includes that spinlocks can still be safely locked, normal
905+
reference counters can be safely manipulated, and ``__rcu`` pointers
906+
can be safely dereferenced.
907+
908+
Some operations that one might expect to see on an object for
909+
which an RCU reference is held include:
910+
911+
- Copying out data that is guaranteed to be stable by the object's type.
912+
- Using kref_get_unless_zero() or similar to get a longer-term
913+
reference. This may fail of course.
914+
- Acquiring a spinlock in the object, and checking if the object still
915+
is the expected object and if so, manipulating it freely.
916+
917+
The understanding that RCU provides a reference that only prevents a
918+
change of type is particularly visible with objects allocated from a
919+
slab cache marked ``SLAB_TYPESAFE_BY_RCU``. RCU operations may yield a
920+
reference to an object from such a cache that has been concurrently
921+
freed and the memory reallocated to a completely different object,
922+
though of the same type. In this case RCU doesn't even protect the
923+
identity of the object from changing, only its type. So the object
924+
found may not be the one expected, but it will be one where it is safe
925+
to take a reference or spinlock and then confirm that the identity
926+
matches the expectations.
927+
928+
With traditional reference counting -- such as that implemented by the
929+
kref library in Linux -- there is typically code that runs when the last
930+
reference to an object is dropped. With kref, this is the function
931+
passed to kref_put(). When RCU is being used, such finalization code
932+
must not be run until all ``__rcu`` pointers referencing the object have
933+
been updated, and then a grace period has passed. Every remaining
934+
globally visible pointer to the object must be considered to be a
935+
potential counted reference, and the finalization code is typically run
936+
using call_rcu() only after all those pointers have been changed.
937+
938+
To see how to choose between these two analogies -- of RCU as a
939+
reader-writer lock and RCU as a reference counting system -- it is useful
940+
to reflect on the scale of the thing being protected. The reader-writer
941+
lock analogy looks at larger multi-part objects such as a linked list
942+
and shows how RCU can facilitate concurrency while elements are added
943+
to, and removed from, the list. The reference-count analogy looks at
944+
the individual objects and looks at how they can be accessed safely
945+
within whatever whole they are a part of.
946+
947+
.. _8_whatisRCU:
948+
949+
8. FULL LIST OF RCU APIs
876950
-------------------------
877951

878952
The RCU APIs are documented in docbook-format header comments in the
@@ -1035,9 +1109,9 @@ g. Otherwise, use RCU.
10351109
Of course, this all assumes that you have determined that RCU is in fact
10361110
the right tool for your job.
10371111

1038-
.. _8_whatisRCU:
1112+
.. _9_whatisRCU:
10391113

1040-
8. ANSWERS TO QUICK QUIZZES
1114+
9. ANSWERS TO QUICK QUIZZES
10411115
----------------------------
10421116

10431117
Quick Quiz #1:

0 commit comments

Comments
 (0)