1*4882a593Smuzhiyun.. _rcu_doc: 2*4882a593Smuzhiyun 3*4882a593SmuzhiyunRCU Concepts 4*4882a593Smuzhiyun============ 5*4882a593Smuzhiyun 6*4882a593SmuzhiyunThe basic idea behind RCU (read-copy update) is to split destructive 7*4882a593Smuzhiyunoperations into two parts, one that prevents anyone from seeing the data 8*4882a593Smuzhiyunitem being destroyed, and one that actually carries out the destruction. 9*4882a593SmuzhiyunA "grace period" must elapse between the two parts, and this grace period 10*4882a593Smuzhiyunmust be long enough that any readers accessing the item being deleted have 11*4882a593Smuzhiyunsince dropped their references. For example, an RCU-protected deletion 12*4882a593Smuzhiyunfrom a linked list would first remove the item from the list, wait for 13*4882a593Smuzhiyuna grace period to elapse, then free the element. See the 14*4882a593Smuzhiyun:ref:`Documentation/RCU/listRCU.rst <list_rcu_doc>` for more information on 15*4882a593Smuzhiyunusing RCU with linked lists. 16*4882a593Smuzhiyun 17*4882a593SmuzhiyunFrequently Asked Questions 18*4882a593Smuzhiyun-------------------------- 19*4882a593Smuzhiyun 20*4882a593Smuzhiyun- Why would anyone want to use RCU? 21*4882a593Smuzhiyun 22*4882a593Smuzhiyun The advantage of RCU's two-part approach is that RCU readers need 23*4882a593Smuzhiyun not acquire any locks, perform any atomic instructions, write to 24*4882a593Smuzhiyun shared memory, or (on CPUs other than Alpha) execute any memory 25*4882a593Smuzhiyun barriers. The fact that these operations are quite expensive 26*4882a593Smuzhiyun on modern CPUs is what gives RCU its performance advantages 27*4882a593Smuzhiyun in read-mostly situations. The fact that RCU readers need not 28*4882a593Smuzhiyun acquire locks can also greatly simplify deadlock-avoidance code. 29*4882a593Smuzhiyun 30*4882a593Smuzhiyun- How can the updater tell when a grace period has completed 31*4882a593Smuzhiyun if the RCU readers give no indication when they are done? 32*4882a593Smuzhiyun 33*4882a593Smuzhiyun Just as with spinlocks, RCU readers are not permitted to 34*4882a593Smuzhiyun block, switch to user-mode execution, or enter the idle loop. 35*4882a593Smuzhiyun Therefore, as soon as a CPU is seen passing through any of these 36*4882a593Smuzhiyun three states, we know that that CPU has exited any previous RCU 37*4882a593Smuzhiyun read-side critical sections. So, if we remove an item from a 38*4882a593Smuzhiyun linked list, and then wait until all CPUs have switched context, 39*4882a593Smuzhiyun executed in user mode, or executed in the idle loop, we can 40*4882a593Smuzhiyun safely free up that item. 41*4882a593Smuzhiyun 42*4882a593Smuzhiyun Preemptible variants of RCU (CONFIG_PREEMPT_RCU) get the 43*4882a593Smuzhiyun same effect, but require that the readers manipulate CPU-local 44*4882a593Smuzhiyun counters. These counters allow limited types of blocking within 45*4882a593Smuzhiyun RCU read-side critical sections. SRCU also uses CPU-local 46*4882a593Smuzhiyun counters, and permits general blocking within RCU read-side 47*4882a593Smuzhiyun critical sections. These variants of RCU detect grace periods 48*4882a593Smuzhiyun by sampling these counters. 49*4882a593Smuzhiyun 50*4882a593Smuzhiyun- If I am running on a uniprocessor kernel, which can only do one 51*4882a593Smuzhiyun thing at a time, why should I wait for a grace period? 52*4882a593Smuzhiyun 53*4882a593Smuzhiyun See :ref:`Documentation/RCU/UP.rst <up_doc>` for more information. 54*4882a593Smuzhiyun 55*4882a593Smuzhiyun- How can I see where RCU is currently used in the Linux kernel? 56*4882a593Smuzhiyun 57*4882a593Smuzhiyun Search for "rcu_read_lock", "rcu_read_unlock", "call_rcu", 58*4882a593Smuzhiyun "rcu_read_lock_bh", "rcu_read_unlock_bh", "srcu_read_lock", 59*4882a593Smuzhiyun "srcu_read_unlock", "synchronize_rcu", "synchronize_net", 60*4882a593Smuzhiyun "synchronize_srcu", and the other RCU primitives. Or grab one 61*4882a593Smuzhiyun of the cscope databases from: 62*4882a593Smuzhiyun 63*4882a593Smuzhiyun (http://www.rdrop.com/users/paulmck/RCU/linuxusage/rculocktab.html). 64*4882a593Smuzhiyun 65*4882a593Smuzhiyun- What guidelines should I follow when writing code that uses RCU? 66*4882a593Smuzhiyun 67*4882a593Smuzhiyun See the checklist.txt file in this directory. 68*4882a593Smuzhiyun 69*4882a593Smuzhiyun- Why the name "RCU"? 70*4882a593Smuzhiyun 71*4882a593Smuzhiyun "RCU" stands for "read-copy update". 72*4882a593Smuzhiyun :ref:`Documentation/RCU/listRCU.rst <list_rcu_doc>` has more information on where 73*4882a593Smuzhiyun this name came from, search for "read-copy update" to find it. 74*4882a593Smuzhiyun 75*4882a593Smuzhiyun- I hear that RCU is patented? What is with that? 76*4882a593Smuzhiyun 77*4882a593Smuzhiyun Yes, it is. There are several known patents related to RCU, 78*4882a593Smuzhiyun search for the string "Patent" in Documentation/RCU/RTFP.txt to find them. 79*4882a593Smuzhiyun Of these, one was allowed to lapse by the assignee, and the 80*4882a593Smuzhiyun others have been contributed to the Linux kernel under GPL. 81*4882a593Smuzhiyun There are now also LGPL implementations of user-level RCU 82*4882a593Smuzhiyun available (https://liburcu.org/). 83*4882a593Smuzhiyun 84*4882a593Smuzhiyun- I hear that RCU needs work in order to support realtime kernels? 85*4882a593Smuzhiyun 86*4882a593Smuzhiyun Realtime-friendly RCU can be enabled via the CONFIG_PREEMPT_RCU 87*4882a593Smuzhiyun kernel configuration parameter. 88*4882a593Smuzhiyun 89*4882a593Smuzhiyun- Where can I find more information on RCU? 90*4882a593Smuzhiyun 91*4882a593Smuzhiyun See the Documentation/RCU/RTFP.txt file. 92*4882a593Smuzhiyun Or point your browser at (http://www.rdrop.com/users/paulmck/RCU/). 93