Design/Requirements/Requirements.rst

2 A Tour Through RCU's Requirements
18 Read-copy update (RCU) is a synchronization mechanism that is often used
19 as a replacement for reader-writer locking. RCU is unusual in that
20 updaters do not block readers, which means that RCU's read-side
23 this concurrency between RCU readers and updaters does raise the
24 question of exactly what RCU readers are doing, which in turn raises the
25 question of exactly what RCU's requirements are.
27 This document therefore summarizes RCU's requirements, and can be
28 thought of as an informal, high-level specification for RCU. It is
29 important to understand that RCU's specification is primarily empirical
36 All that aside, here are the categories of currently known RCU
45 #. `Other RCU Flavors`_
55 RCU's fundamental requirements are the closest thing RCU has to hard
61 #. `RCU Primitives Guaranteed to Execute Unconditionally`_
67 RCU's grace-period guarantee is unusual in being premeditated: Jack
69 on RCU (then called “rclock”) in the early 1990s. That said, the past
70 two decades of experience with RCU have produced a much more detailed
73 RCU's grace-period guarantee allows updaters to wait for the completion
74 of all pre-existing RCU read-side critical sections. An RCU read-side
77 RCU treats a nested set as one big RCU read-side critical section.
135 This scenario resembles one of the first uses of RCU in
173 The RCU read-side critical section in do_something_dlm() works with
190 In order to avoid fatal problems such as deadlocks, an RCU read-side
192 Similarly, an RCU read-side critical section must not contain anything
196 Although RCU's grace-period guarantee is useful in and of itself, with
198 be good to be able to use RCU to coordinate read-side access to linked
246 If an RCU reader fetches ``gp`` just after ``add_gp_buggy_optimized``
257 RCU's publish-subscribe guarantee allows data to be inserted into a
258 linked data structure without disrupting RCU readers. The updater uses
305 control its accesses to the RCU-protected data, as shown in
370 outermost RCU read-side critical section containing that
372 element has been passed from RCU to some other synchronization
377 …tion of C11 memory_order_consume [PDF]: http://www.rdrop.com/users/paulmck/RCU/consume.2015.07.13a…
380 rcu_dereference(), and these two RCU API elements work together to
383 Of course, it is also necessary to remove elements from RCU-protected
387 #. Wait for all pre-existing RCU read-side critical sections to complete
426    contrast, rcu_dereference() must either be within an RCU
456 In short, RCU's publish-subscribe guarantee is provided by the
458 guarantee allows data elements to be safely added to RCU-protected
459 linked data structures without disrupting RCU readers. This guarantee
461 data elements to be removed from RCU-protected linked data structures,
462 again without disrupting RCU readers.
484 demonstrates the need for RCU's stringent memory-ordering guarantees on
487 #. Each CPU that has an RCU read-side critical section that begins
489    memory barrier between the time that the RCU read-side critical
491    this guarantee, a pre-existing RCU read-side critical section might
494 #. Each CPU that has an RCU read-side critical section that ends after
497    time that the RCU read-side critical section begins. Without this
498    guarantee, a later RCU read-side critical section running after the
517 | Given that multiple CPUs can start RCU read-side critical sections at |
518 | any time without any ordering whatsoever, how can RCU possibly tell   |
519 | whether or not a given RCU read-side critical section starts before a |
524 | If RCU cannot tell whether or not a given RCU read-side critical      |
526 | it must assume that the RCU read-side critical section started first. |
528 | waiting on a given RCU read-side critical section only if it can      |
534 | within the enclosed RCU read-side critical section to the code        |
536 | then a given RCU read-side critical section begins before a given     |
542 | As of late 2016, mathematical models of RCU take this viewpoint, for  |
571 | end of the RCU read-side critical section and the end of the grace    |
588 | grace period and the beginning of the RCU read-side critical section, |
603 | compiler might arbitrarily rearrange consecutive RCU read-side        |
604 | critical sections. Given such rearrangement, if a given RCU read-side |
605 | critical section is done, how can you be sure that all prior RCU      |
612 | absolutely no code, RCU infers quiescent states only at special       |
616 | RCU detects the end of a given RCU read-side critical section, it     |
617 | will necessarily detect the end of all prior RCU read-side critical   |
622 | that sort of scrambling, you have broken far more than just RCU!      |
626 fundamental RCU requirement that a grace period wait for all
632 RCU Primitives Guaranteed to Execute Unconditionally
635 The common-case RCU primitives are unconditional. They are invoked, they
637 to retry. This is a key RCU design philosophy.
640 comes up with a good justification for a particular conditional RCU
643 nature of the RCU primitives was initially an accident of
647 primitive to RCU would need to be based on detailed and compelling use
653 As far as RCU is concerned, it is always possible to carry out an update
654 within an RCU read-side critical section. For example, that RCU
657 element, all while remaining in that RCU read-side critical section. Of
658 course, it is necessary to exit the RCU read-side critical section
670 | It doesn't, just like normal RCU updates, which also do not exclude   |
671 | RCU readers.                                                          |
676 DYNIX/ptx RCU documentation.
681 RCU provides extremely lightweight readers, and its read-side
683 therefore all too easy to assume that RCU is guaranteeing more than it
684 really is. Of course, the list of things that RCU does not guarantee is
812 It is tempting to assume that if any part of one RCU read-side critical
813 section precedes a given grace period, and if any part of another RCU
815 the first RCU read-side critical section must precede all of the second.
817 partition the set of RCU read-side critical sections. An example of this
853 with each circled ``QS`` indicating the point at which RCU recorded a
854 *quiescent state* for each thread, that is, a state in which RCU knows
855 that the thread cannot be in the midst of an RCU read-side critical
860 If it is necessary to partition RCU read-side critical sections in this
902 the two RCU read-side critical sections cannot overlap, guaranteeing
912 studying RCU's interaction with memory ordering.
917 It is also tempting to assume that if an RCU read-side critical section
972 Again, an RCU read-side critical section can overlap almost all of a
974 period. As a result, an RCU read-side critical section cannot partition
975 a pair of RCU grace periods.
980 | How long a sequence of grace periods, each separated by an RCU        |
981 | read-side critical section, would be required to partition the RCU    |
988 | Therefore, even in practice, RCU users must abide by the theoretical  |
995 These parallelism facts of life are by no means specific to RCU, but the
996 RCU implementation must abide by them. They therefore bear repeating:
1005    than about 20 seconds can result in splats, the RCU implementation is
1010    matters, RCU must use compiler directives and memory-barrier
1015    dramatic slowdowns. RCU is therefore obligated to use algorithms that
1019    carried out under the protection of any given exclusive lock. RCU
1021 #. Counters are finite, especially on 32-bit systems. RCU's use of
1025    a century much less so. As an example of the latter, RCU's
1033    kernel in a single shared-memory environment. RCU must therefore pay
1036 This last parallelism fact of life means that RCU must pay special
1046 RCU implementation that ignores these requirements could still be used,
1062 RCU is and always has been intended primarily for read-mostly
1063 situations, which means that RCU's read-side primitives are optimized,
1068    RCU works great!
1069 #. Read-mostly data, where data must be consistent: RCU works well.
1070 #. Read-write data, where data must be consistent: RCU *might* work OK.
1072 #. Write-mostly data, where data must be consistent: RCU is very
1074    exceptions, where RCU can provide:
1079 This focus on read-mostly situations means that RCU must interoperate
1081 remove_gp_synchronous() examples discussed earlier use RCU to
1084 primitives be legal within RCU read-side critical sections, including
1095 | These are forbidden within Linux-kernel RCU read-side critical        |
1097 | case, voluntary context switch) within an RCU read-side critical      |
1098 | section. However, sleeping locks may be used within userspace RCU     |
1100 | RCU `(SRCU) <Sleepable RCU_>`__ read-side critical sections. In       |
1104 | locks!) may be acquire within -rt-Linux-kernel RCU read-side critical |
1106 | Note that it *is* legal for a normal RCU read-side critical section   |
1153 to the corresponding in-kernel data structure is protected by RCU, but
1157 within the RCU read-side critical section, and this is indicated by the
1161 In short, RCU is not required to maintain consistency, and other
1162 mechanisms may be used in concert with RCU when consistency is required.
1163 RCU's specialization allows it to do its job extremely well, and its
1171 Linux-kernel RCU implementations must therefore avoid unnecessarily
1176 energy-efficiency shortcomings of the Linux-kernel RCU implementation.
1187 RCU <https://lore.kernel.org/r/20090113221724.GA15307@linux.vnet.ibm.com>`__
1194 unsurprising. For example, in keeping with RCU's read-side
1200 In preemptible environments, in the case where the RCU read-side
1206 branches. However, in the case where the RCU read-side critical section
1208 interrupts. This is why it is better to nest an RCU read-side critical
1215 addition to the duration of the longest RCU read-side critical section.
1221 invocations <https://www.usenix.org/conference/2004-usenix-annual-technical-conference/making-rcu-s…
1230 microseconds on small systems, at least in cases where the RCU read-side
1233 consistent with the empirical nature of the RCU specification, that is
1292 userspace, it is bad practice to write an RCU callback function that
1348 fact that RCU was not heavily used within DYNIX/ptx, so the very few
1401 On line 14, get_state_synchronize_rcu() obtains a “cookie” from RCU,
1408 RCU thus provides a range of tools to allow updaters to strike the
1417 difficult to distinguish from system hangs. Therefore, RCU must provide
1421 example, an infinite loop in an RCU read-side critical section must by
1431 responsibility. However, short of this level of abuse, RCU is required
1435 RCU takes the following steps to encourage timely completion of grace
1438 #. If a grace period fails to complete within 100 milliseconds, RCU
1440    to provide an RCU quiescent state. RCU also causes those CPUs'
1445    defeats the above need_resched() strategem. RCU will therefore
1449    has been preempted within an RCU read-side critical section is
1450    holding out for more than 500 milliseconds, RCU will resort to
1452 #. If a CPU is still holding out 10 seconds into the grace period, RCU
1458 the relevant Kconfig options and kernel boot parameters. RCU currently
1461 are provided only for RCU, not for `SRCU <Sleepable RCU_>`__ or `Tasks
1462 RCU`_.
1464 RCU takes the following steps in call_rcu() to encourage timely
1481 RCU, not for `SRCU <Sleepable RCU_>`__ or `Tasks
1482 RCU`_. Even for RCU, callback-invocation forward
1495 use. And in theory, RCU read-side critical sections may be composed, and
1500 Implementations of RCU for which rcu_read_lock() and
1501 rcu_read_unlock() generate no code, such as Linux-kernel RCU when
1511 kernel) you will get an RCU CPU stall warning. Nevertheless, this class
1512 of RCU implementations is one of the most composable constructs in
1515 RCU implementations that explicitly track nesting depth are limited by
1517 RCU limits nesting to ``INT_MAX``. This should suffice for almost all
1518 practical purposes. That said, a consecutive pair of RCU read-side
1520 grace period cannot be enclosed in another RCU read-side critical
1522 within an RCU read-side critical section: To do so would result either
1523 in deadlock or in RCU implicitly splitting the enclosing RCU read-side
1527 It is worth noting that RCU is not alone in limiting composability. For
1534 In short, although RCU read-side critical sections are highly
1541 A given RCU workload might have an endless and intense stream of RCU
1543 never a point in time during which there was not at least one RCU
1544 read-side critical section in flight. RCU cannot allow this situation to
1545 block grace periods: As long as all the RCU read-side critical sections
1548 That said, preemptible RCU implementations could potentially result in
1549 RCU read-side critical sections being preempted for long durations,
1550 which has the effect of creating a long-duration RCU read-side critical
1553 Therefore, RCU priority boosting is provided to help deal with this
1554 case. That said, the exact requirements on RCU priority boosting will
1558 argue that such workloads should instead use something other than RCU,
1559 the fact remains that RCU must handle such workloads gracefully. This
1562 RCU callbacks in the call_rcu() code path. Finally, high update
1563 rates should not delay RCU read-side critical sections, although some
1572 motivated addition of some RCU code to react to high update rates, for
1573 example, if a given CPU finds itself with more than 10,000 RCU callbacks
1574 queued, it will cause RCU to take evasive action by more aggressively
1577 complete more quickly, but at the cost of restricting RCU's batching
1589    splat if rcu_dereference() is used outside of an RCU read-side
1602    that it has been invoked within an RCU read-side critical section. I
1604    Gleixner audited a number of RCU uses.
1605 #. A given function might wish to check for RCU-related preconditions
1606    upon entry, before using any other RCU API. The
1611    assignment. To catch this sort of error, a given RCU-protected
1629 #. An infinite loop in an RCU read-side critical section will eventually
1630    trigger an RCU CPU stall warning splat, with the duration of
1633    ``rcupdate.rcu_cpu_stall_timeout`` boot/sysfs parameter. However, RCU
1635    waiting on that particular RCU read-side critical section.
1637    Some extreme workloads might intentionally delay RCU grace periods,
1640    kernel parameter may also be set via ``sysfs``. Furthermore, RCU CPU
1642    panics. RCU therefore supplies the rcu_sysrq_start() and
1644    sysrq dumps. RCU also supplies the rcu_panic() notifier that is
1646    RCU CPU stall warnings.
1653 #. Although it would be very good to detect pointers leaking out of RCU
1656    leaking and pointers that have been handed off from RCU to some other
1658 #. In kernels built with ``CONFIG_RCU_TRACE=y``, RCU-related information
1662    error-prone. Therefore, RCU-protected `linked
1663    lists <https://lwn.net/Articles/609973/#RCU%20List%20APIs>`__ and,
1664    more recently, RCU-protected `hash
1666    other special-purpose RCU-protected data structures are available in
1667    the Linux kernel and the userspace RCU library.
1675 This not a hard-and-fast list: RCU's diagnostic capabilities will
1677 real-world RCU usage.
1683 software, including RCU. Some of the relevant points of interest are as
1692 #. `Scheduler and RCU`_
1693 #. `Tracing and RCU`_
1694 #. `Accesses to User Memory and RCU`_
1696 #. `Scheduling-Clock Interrupts and RCU`_
1707 RCU's goal is automatic configuration, so that almost nobody needs to
1708 worry about RCU's ``Kconfig`` options. And for almost all users, RCU
1730 sometimes by a large factor. If RCU naively believed the firmware, as it
1736 RCU must therefore wait for a given CPU to actually come online before
1745 The Linux kernel's boot sequence is an interesting process, and RCU is
1747 RCU's primitives can be used as soon as the initial task's
1755 callbacks are not guaranteed to be invoked until after all of RCU's
1757 This delay in callback invocation is due to the fact that RCU does not
1760 itself to the point where RCU can spawn and run its kthreads. In theory,
1775 reason is that an RCU read-side critical section might be preempted,
1780 early_initcalls() time. But this is no excuse: RCU is nevertheless
1782 period. Once all of its kthreads are up and running, RCU starts running
1788 | How can RCU possibly handle grace periods before all of its kthreads  |
1795 | first task and the time that all of RCU's kthreads have been spawned, |
1808 | kthread and the time that RCU's kthreads have all been spawned. If    |
1821 The Linux kernel has interrupts, and RCU read-side critical sections are
1829 “half-interrupts” mean that RCU has to be very careful about how it
1831 way during a rewrite of RCU's dyntick-idle code.
1833 The Linux kernel has non-maskable interrupts (NMIs), and RCU read-side
1834 critical sections are legal within NMI handlers. Thankfully, RCU
1839 nested NMIs, which RCU must handle correctly. Andy Lutomirski `surprised
1845 Furthermore, NMI handlers can be interrupted by what appear to RCU to be
1863 Unfortunately, there is no way to cancel an RCU callback; once you
1867 module unload request, we need some other way to deal with in-flight RCU
1870 RCU therefore provides rcu_barrier(), which waits until all
1871 in-flight RCU callbacks have been invoked. If a module uses
1880 rcu_barrier() into RCU. The need for rcu_barrier() for module
1887    to wait for RCU callbacks that have already been posted. Therefore, if
1888    there are no RCU callbacks posted anywhere in the system,
1896 | Wait a minute! Each RCU callbacks must wait for a grace period to     |
1905 | Yes, each RCU callbacks must wait for a grace period to complete, but |
1922 and go. It is of course illegal to use any RCU API member from an
1929 to allow the various kernel subsystems (including RCU) to respond
1930 appropriately to a given CPU-hotplug operation. Most RCU operations may
1947 Finally, RCU must avoid deadlocks due to interaction between hotplug,
1954 if offline CPUs block an RCU grace period for too long.
1958 1.  As the CPU goes offline using RCU's hotplug notifier (rcutree_report_cpu_dead()).
1968 During the checking/modification of RCU's hotplug bookkeeping, the
1970 between RCU's hotplug notifier hooks, the grace period initialization
1973 Scheduler and RCU
1976 RCU makes use of kthreads, and it is necessary to avoid excessive CPU-time
1978 RCU's violation of it when running context-switch-heavy workloads when
1981 RCU has made good progress towards meeting this requirement, even for
1988 somewhere within the corresponding RCU read-side critical section.
1993 Similarly, the RCU flavor consolidation has removed the need for negative
1994 nesting.  The fact that interrupt-disabled regions of code act as RCU
1996 to result in destructive recursion via interrupt handler's use of RCU.
1998 Tracing and RCU
2001 It is possible to use tracing on RCU code, but tracing itself uses RCU.
2005 where RCU readers execute in environments in which tracing cannot be
2009 Accesses to User Memory and RCU
2018 reorder a get_user() invocation into an RCU read-side critical section.
2045 state in the middle of an RCU read-side critical section.  This misplaced
2060 of RCU read-side critical sections.
2066 by people with battery-powered embedded systems. RCU therefore conserves
2072 Because RCU avoids interrupting idle CPUs, it is illegal to execute an
2073 RCU read-side critical section on an idle CPU. (Kernels built with
2077 running in userspace. RCU must therefore track ``nohz_full`` userspace
2078 execution. RCU must therefore be able to sample state at two points in
2084 clean-sheet rewrites of RCU's energy-efficiency code, the last of which
2090 not sufficient to fully vent their ire at RCU's energy-efficiency bugs!
2092 Scheduling-Clock Interrupts and RCU
2096 execution, and the idle loop. Depending on kernel configuration, RCU
2103 |                 | scheduling-clock | scheduling-clock | RCU's           |
2110 |                 | scheduling-clock | scheduling-clock | RCU's           |
2117 |                 | sometimes rely   | RCU's            | RCU's           |
2143 However, RCU must be reliably informed as to whether any given CPU is
2147 scheduling-clock interrupt be enabled when RCU needs it to be:
2149 #. If a CPU is either idle or executing in usermode, and RCU believes it
2151    Otherwise, you will get RCU CPU stall warnings. Or at best, very long
2154 #. If a CPU is in a portion of the kernel that executes RCU read-side
2155    critical sections, and RCU believes this CPU to be idle, you will get
2160    no-joking guaranteed to never execute any RCU read-side critical
2161    sections, and RCU believes this CPU to be idle, no problem. This
2169    fact joking about not doing RCU read-side critical sections.
2171    interrupt disabled and RCU believes this CPU to be non-idle, and if
2172    the CPU goes idle (from an RCU perspective) every few jiffies, no
2175    If the gap grows too long, you get RCU CPU stall warnings.
2176 #. If a CPU is either idle or executing in usermode, and RCU believes it
2184    long, you get RCU CPU stall warnings.
2201 But as long as RCU is properly informed of kernel state transitions
2203 as the scheduling-clock interrupt is enabled when RCU needs it to be,
2205 part of RCU or some other part of the kernel!
2210 Although small-memory non-realtime systems can simply use Tiny RCU, code
2214 pair of pointers, it does appear in many RCU-protected data structures,
2219 This need for memory efficiency is one reason that RCU uses hand-crafted
2237 ``->next`` field. RCU makes this guarantee as long as call_rcu() is
2242 That said, there are limits. RCU requires that the ``rcu_head``
2263 discussion <Performance and Scalability_>`__, RCU is used heavily by
2265 networking, security, virtualization, and scheduling code paths. RCU
2267 read-side primitives. To that end, it would be good if preemptible RCU's
2273 which means that RCU must be extremely scalable. Algorithms that involve
2275 global variables simply cannot be tolerated within the RCU
2276 implementation. RCU therefore makes heavy use of a combining tree based
2277 on the ``rcu_node`` structure. RCU is required to tolerate all CPUs
2278 continuously invoking any combination of RCU's runtime primitives with
2283 rule, RCU must cheerfully accept whatever the rest of the Linux kernel
2290 approach of disabling preemption across RCU read-side critical sections
2292 an RCU implementation that allows RCU read-side critical sections to be
2296 conjunction with some `RCU
2300 In addition, RCU must make do with a sub-100-microsecond real-time
2303 whole kernel, including RCU. RCU's scalability and latency must
2312 RCU must avoid degrading real-time response for CPU-bound threads,
2316 milliseconds in order to avoid receiving an IPI from RCU.
2318 Finally, RCU's status as a synchronization primitive means that any RCU
2320 difficult to debug. This means that RCU must be extremely reliable,
2321 which in practice also means that RCU must have an aggressive
2332 Suppose that RCU contains a race condition that manifests on average
2334 three times per *day* across the installed base. RCU could simply hide
2343 bug in RCU killed someone. Which might explain my recent focus on
2346 Other RCU Flavors
2349 One of the more surprising things about RCU is that there are now no
2358 #. `Sleepable RCU`_
2359 #. `Tasks RCU`_
2360 #. `Tasks Trace RCU`_
2365 The RCU-bh flavor of RCU has since been expressed in terms of the other
2366 RCU flavors as part of a consolidation of the three flavors into a
2372 flavor of RCU, or *RCU-bh*, was developed by Dipankar Sarma to provide a
2373 flavor of RCU that could withstand the network-based denial-of-service
2377 context switch, which, in the RCU implementation of that time, prevented
2381 The solution was the creation of RCU-bh, which does
2385 offline. This means that RCU-bh grace periods can complete even when
2387 algorithms based on RCU-bh to withstand network-based denial-of-service
2392 during the RCU-bh read-side critical section will be deferred. In this
2395 overhead should be associated with the code following the RCU-bh
2399 RCU-bh read-side critical section executes during a time of heavy
2406 The `RCU-bh
2407 API <https://lwn.net/Articles/609973/#RCU%20Per-Flavor%20API%20Table>`__
2410 old RCU-bh update-side APIs are now gone, replaced by synchronize_rcu(),
2412 anything that disables bottom halves also marks an RCU-bh read-side
2419 The RCU-sched flavor of RCU has since been expressed in terms of the
2420 other RCU flavors as part of a consolidation of the three flavors into a
2425 Before preemptible RCU, waiting for an RCU grace period had the side
2427 However, there are legitimate preemptible-RCU implementations that do
2429 RCU read-side critical section can be a quiescent state. Therefore,
2430 *RCU-sched* was created, which follows “classic” RCU in that an
2431 RCU-sched grace period waits for pre-existing interrupt and NMI
2432 handlers. In kernels built with ``CONFIG_PREEMPTION=n``, the RCU and
2433 RCU-sched APIs have identical implementations, while kernels built with
2439 preemption attempt during the RCU-sched read-side critical section,
2447 The `RCU-sched
2448 API <https://lwn.net/Articles/609973/#RCU%20Per-Flavor%20API%20Table>`__
2452 rcu_read_lock_sched_held().  However, the old RCU-sched update-side APIs
2455 preemption also marks an RCU-sched read-side critical section,
2459 Sleepable RCU
2462 For well over a decade, someone saying “I need to block within an RCU
2464 did not understand RCU. After all, if you are always blocking in an RCU
2467 the advent of the Linux kernel's notifiers, whose RCU read-side critical
2469 introduction of `sleepable RCU <https://lwn.net/Articles/202847/>`__, or
2518 Unlike the other RCU flavors, SRCU read-side critical sections can run
2521 which means that SRCU readers will run a bit slower than would RCU
2526 Also unlike other RCU flavors, synchronize_srcu() may **not** be
2538 SRCU also differs from other RCU flavors in that SRCU's expedited and
2561 API <https://lwn.net/Articles/609973/#RCU%20Per-Flavor%20API%20Table>`__
2588 Tasks RCU
2594 RCU. However, because it is necessary to be able to install a trace
2609 RCU <https://lwn.net/Articles/607117/>`__, is to have implicit read-side
2613 userspace execution also delimit tasks-RCU read-side critical sections.
2614 Idle tasks are ignored by Tasks RCU, and Tasks Rude RCU may be used to
2617 Note well that involuntary context switches are *not* Tasks-RCU quiescent
2619 trampoline might be preempted.  In this case, the Tasks-RCU grace period
2622 not provide a Tasks RCU quiescent state.  (Instead, use rcu_softirq_qs()
2625 The tasks-RCU API is quite compact, consisting only of
2634 Tasks Rude RCU
2638 of code running on any online CPU, including those executed when RCU is
2640 Tasks Rude RCU must be used instead.  This flavor of RCU does its work by
2647 ``noinstr``, Tasks RCU can start paying attention to idle tasks (except
2648 those that are idle from RCU's perspective) and then Tasks Rude RCU can
2651 The tasks-rude-RCU API is also reader-marking-free and thus quite compact,
2654 Tasks Trace RCU
2660 Tasks Trace RCU that uses scheduler locking and IPIs to synchronize with
2665 The tasks-trace-RCU API is also reasonably compact,
2673 One of the tricks that RCU uses to attain update-side scalability is to
2679 RCU disables CPU hotplug in a few places, perhaps most notably in the
2692 The multiprocessor implementations of RCU use a combining tree that
2710 Please note that arrangements that require RCU to remap CPU numbers will
2714 RCU's various kthreads are reasonably recent additions. It is quite
2717 utilization by RCU's kthreads and softirq handlers to the code that
2718 instigated this CPU utilization. For example, RCU callback overhead
2729 This document has presented more than two decade's worth of RCU