.1 12div id="search_results" class="search_results"
1 112/a>RCU Concepts
1 122/a> 1 132/a> 1 142/a>The basic idea behind RCU (read-copy update) is to split destructive 1 152/a>operations into two parts, one that prevents anyone from seeing the data 1 162/a>item being destroyed, and one that actually carries out the destruction. 1 172/a>A "grace period" must elapse between the two parts, and this grace period 1 182/a>must be long enough that any readers accessing the item being deleted have 1 192/a>since dropped their references. For example, an RCU-protacted deletion 1 10from a linked list would first remove the item from the list, wait for 1 112/a>a grace period to elapse, then free the element. See the listRCU.txt 1 122/a>file for more information on using RCU with linked lists. 1 132/a> 1 142/a> 1 152/a>Frequently Asked Questions 1 162/a> 1 172/a>oal.1 1 Why would anyone want to use RCU? 1 182/a> 1 192/a>al.1 1 The advantage of RCU's two-part approach is that RCU readers need 1 202/a>al.1 1 not acquire any locks, perform any atomic instructions, write to 1 212/a>al.1 1 shared memory, or (on CPUs other than Alpha) execute any memory 1 222/a>al.1 1 barriers. The fact that these operations are quite expensive 1 232/a>al.1 1 on modern CPUs is what gives RCU its performance advantages
1 242/a>al.1 1 in read-mostly situations. The fact that RCU readers need not
1 252/a>al.1 1 acquire locks can also greatly simplify deadlock-avoidance code. 1 262/a> 1 272/a>oal.1 1 How can the updater tell when a grace period has completed 1 282/a>al.1 1 if the RCU readers give no indication when they are done? 1 292/a> 1 302/a>al.1 1 Just as with spinlocks, RCU readers are not permitted to 1 312/a>al.1 1 block, switch to user-mode execution, or enter the idle loop. 1 322/a>al.1 1 Therefore, as soon as a CPU is seen passing through any of these 1 332/a>al.1 1 three states, we know that that CPU has exited any previous RCU 1 342/a>al.1 1 read-side critical sections. So, if we remove an item from a 1 352/a>al.1 1 linked list, and then wait until all CPUs have switched context, 1 362/a>al.1 1 executed in user mode, or executed in the idle loop, we can 1 372/a>al.1 1 safely free up that item. 1 382/a> 1 392/a>al.1 1 Preemptible variants of RCU (CONFIG_TREE_PREEMPT_RCU) get the 1 402/a>al.1 1 same effect, but require that the readers manipulate CPU-local 1 412/a>al.1 1 counters. These counters allow limited types of blocking within 1 422/a>al.1 1 RCU read-side critical sections. SRCU also uses CPU-local 1 432/a>al.1 1 counters, and permits general blocking within RCU read-side 1 442/a>al.1 1 critical sections. These variants of RCU detact grace periods
1 452/a>al.1 1 by sampling these counters. 1 462/a> 1 472/a>oal.1 1 If I am running on a uniprocessor kernel, which can only do one 1 482/a>al.1 1 thing at a time, why should I wait for a grace period? 1 492/a> 1 502/a>al.1 1 See the UP.txt file in this directory. 1 512/a> 1 522/a>oal.1 1 How can I see where RCU is currently used in the Linux kernel? 1 532/a> 1 542/a>al.1 1 Search for "rcu_read_lock", "rcu_read_unlock", "call_rcu", 1 552/a>al.1 1 "rcu_read_lock_bh", "rcu_read_unlock_bh", "call_rcu_bh", 1 562/a>al.1 1 "srcu_read_lock", "srcu_read_unlock", "synchronize_rcu", 1 572/a>al.1 1 "synchronize_net", "synchronize_srcu", and the other RCU 1 582/a>al.1 1 primitives. Or grab one of the cscope databases from: 1 592/a> 1 602/a>al.1 1 http://www.rdrop.com/users/paulmck/RCU/linuxusage/rculocktab.html2/a> 1 612/a> 1 622/a>oal.1 1 What guidelines should I follow when writing code that uses RCU? 1 632/a> 1 642/a>al.1 1 See the checklist.txt file in this directory. 1 652/a> 1 662/a>oal.1 1 Why the name "RCU"? 1 672/a> 1 682/a>al.1 1 "RCU" stands for "read-copy update". The file listRCU.txt has 1 692/a>al.1 1 more information on where this name came from, search for 1 702/a>al.1 1 "read-copy update" to find it. 1 712/a> 1 722/a>oal.1 1 I hear that RCU is patented?1 What is with that? 1 732/a> 1 742/a>al.1 1 Yes, it is. There are several known patents related to RCU, 1 752/a>al.1 1 search for the string "Patent" in RTFP.txt to find them. 1 762/a>al.1 1 Of these, one was allowed to lapse by the assignee, and the 1 772/a>al.1 1 others have been contributed to the Linux kernel under GPL. 1 782/a>al.1 1 There are now also LGPL implementations of user-level RCU 1 792/a>al.1 1 available (http://lttng.org/?q=node/182/a>). 1 802/a> 1 812/a>oal.1 1 I hear that RCU needs work in order to support realtime kernels? 1 822/a> 1 832/a>al.1 1 This work is largely completed. Realtime-friendly RCU can be 1 842/a>al.1 1 enabled via the CONFIG_TREE_PREEMPT_RCU kernel configuration 1 852/a>al.1 1 parameter.1 However, work is in progress for enabling priority 1 862/a>al.1 1 boosting of preempted RCU read-side critical sections. This is 1 872/a>al.1 1 needed if you have CPU-bound realtime threads. 1 882/a> 1 892/a>oal.1 1 Where can I find more information on RCU? 1 902/a> 1 912/a>al.1 1 See the RTFP.txt file in this directory. 1 922/a>al.1 1 Or point your browser at http://www.rdrop.com/users/paulmck/RCU/2/a>. 1 932/a> 1 942/a>oal.1 1 What are all these files in this directory? 1 952/a> 1 962/a>al.1 1 See 00-INDEX for the list. 1 972/a>
The original LXR software by the LXR community2/a>, this experimental version by email@example.com/a>.
lxr.linux.no kindly hosted by Redpill Linpro AS2/a>, provider of Linux consulting and operations services since 1995.