Lines Matching full:side
20 updaters do not block readers, which means that RCU's read-side
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.
131 | Second, even when using ``synchronize_rcu()``, the other update-side |
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
198 be good to be able to use RCU to coordinate read-side access to linked
372 outermost RCU read-side critical section containing that
386 #. Wait for all pre-existing RCU read-side critical sections to complete
426 read-side critical section or in a code segment where the pointer
428 update-side lock.
486 #. Each CPU that has an RCU read-side critical section that begins
488 memory barrier between the time that the RCU read-side critical
490 this guarantee, a pre-existing RCU read-side critical section might
493 #. Each CPU that has an RCU read-side critical section that ends after
496 time that the RCU read-side critical section begins. Without this
497 guarantee, a later RCU read-side critical section running after the
516 | Given that multiple CPUs can start RCU read-side critical sections at |
518 | whether or not a given RCU read-side critical section starts before a |
523 | If RCU cannot tell whether or not a given RCU read-side critical |
525 | it must assume that the RCU read-side critical section started first. |
527 | waiting on a given RCU read-side critical section only if it can |
533 | within the enclosed RCU read-side critical section to the code |
535 | then a given RCU read-side critical section begins before a given |
570 | end of the RCU read-side critical section and the end of the grace |
587 | grace period and the beginning of the RCU read-side critical section, |
602 | compiler might arbitrarily rearrange consecutive RCU read-side |
603 | critical sections. Given such rearrangement, if a given RCU read-side |
605 | read-side critical sections are done? Won't the compiler |
615 | RCU detects the end of a given RCU read-side critical section, it |
616 | will necessarily detect the end of all prior RCU read-side critical |
653 within an RCU read-side critical section. For example, that RCU
654 read-side critical section might search for a given data element, and
655 then might acquire the update-side spinlock in order to update that
656 element, all while remaining in that RCU read-side critical section. Of
657 course, it is necessary to exit the RCU read-side critical section
673 This guarantee allows lookup code to be shared between read-side and
674 update-side code, and was premeditated, appearing in the earliest
680 RCU provides extremely lightweight readers, and its read-side
691 #. `Grace Periods Don't Partition Read-Side Critical Sections`_
692 #. `Read-Side Critical Sections Don't Partition Grace Periods`_
697 Reader-side markers such as ``rcu_read_lock()`` and
808 Grace Periods Don't Partition Read-Side Critical Sections
811 It is tempting to assume that if any part of one RCU read-side critical
813 read-side critical section follows that same grace period, then all of
814 the first RCU read-side critical section must precede all of the second.
816 partition the set of RCU read-side critical sections. An example of this
854 that the thread cannot be in the midst of an RCU read-side critical
859 If it is necessary to partition RCU read-side critical sections in this
901 the two RCU read-side critical sections cannot overlap, guaranteeing
913 Read-Side Critical Sections Don't Partition Grace Periods
916 It is also tempting to assume that if an RCU read-side critical section
971 Again, an RCU read-side critical section can overlap almost all of a
973 period. As a result, an RCU read-side critical section cannot partition
980 | read-side critical section, would be required to partition the RCU |
981 | read-side critical sections at the beginning and end of the chain? |
1062 situations, which means that RCU's read-side primitives are optimized,
1063 often at the expense of its update-side primitives. Experience thus far
1076 b. Wait-free read-side primitives for real-time use.
1083 primitives be legal within RCU read-side critical sections, including
1094 | These are forbidden within Linux-kernel RCU read-side critical |
1096 | case, voluntary context switch) within an RCU read-side critical |
1098 | read-side critical sections, and also within Linux-kernel sleepable |
1099 | RCU `(SRCU) <#Sleepable%20RCU>`__ read-side critical sections. In |
1103 | locks!) may be acquire within -rt-Linux-kernel RCU read-side critical |
1105 | Note that it *is* legal for a normal RCU read-side critical section |
1156 within the RCU read-side critical section, and this is indicated by the
1193 unsurprising. For example, in keeping with RCU's read-side
1199 In preemptible environments, in the case where the RCU read-side
1205 branches. However, in the case where the RCU read-side critical section
1207 interrupts. This is why it is better to nest an RCU read-side critical
1214 addition to the duration of the longest RCU read-side critical section.
1229 microseconds on small systems, at least in cases where the RCU read-side
1420 example, an infinite loop in an RCU read-side critical section must by
1448 has been preempted within an RCU read-side critical section is
1494 use. And in theory, RCU read-side critical sections may be composed, and
1517 practical purposes. That said, a consecutive pair of RCU read-side
1519 grace period cannot be enclosed in another RCU read-side critical
1521 within an RCU read-side critical section: To do so would result either
1522 in deadlock or in RCU implicitly splitting the enclosing RCU read-side
1533 In short, although RCU read-side critical sections are highly
1541 read-side critical sections, perhaps even so intense that there was
1543 read-side critical section in flight. RCU cannot allow this situation to
1544 block grace periods: As long as all the RCU read-side critical sections
1548 RCU read-side critical sections being preempted for long durations,
1549 which has the effect of creating a long-duration RCU read-side critical
1562 rates should not delay RCU read-side critical sections, although some
1563 small read-side delays can occur when using
1588 splat if ``rcu_dereference()`` is used outside of an RCU read-side
1589 critical section. Update-side code can use
1601 that it has been invoked within an RCU read-side critical section. I
1628 #. An infinite loop in an RCU read-side critical section will eventually
1634 waiting on that particular RCU read-side critical section.
1653 read-side critical sections, there is currently no good way of doing
1749 set up. The read-side primitives (``rcu_read_lock()``,
1775 reason is that an RCU read-side critical section might be preempted,
1821 The Linux kernel has interrupts, and RCU read-side critical sections are
1833 The Linux kernel has non-maskable interrupts (NMIs), and RCU read-side
1835 update-side primitives, including ``call_rcu()``, are prohibited within
1923 offline CPU, with the exception of `SRCU <#Sleepable%20RCU>`__ read-side
1958 somewhere within the corresponding RCU read-side critical section.
1965 read-side critical sections implicitly avoids earlier issues that used
1988 reorder a ``get_user()`` invocation into an RCU read-side critical section.
2015 state in the middle of an RCU read-side critical section. This misplaced
2030 of RCU read-side critical sections.
2043 RCU read-side critical section on an idle CPU. (Kernels built with
2047 whether or not it is currently legal to run RCU read-side critical
2158 #. If a CPU is in a portion of the kernel that executes RCU read-side
2164 no-joking guaranteed to never execute any RCU read-side critical
2173 fact joking about not doing RCU read-side critical sections.
2271 read-side primitives. To that end, it would be good if preemptible RCU's
2294 approach of disabling preemption across RCU read-side critical sections
2296 an RCU implementation that allows RCU read-side critical sections to be
2370 single flavor. The read-side API remains, and continues to disable
2385 ``local_bh_disable()`` across its read-side critical sections, and which
2395 during the RCU-bh read-side critical section will be deferred. In this
2399 read-side critical section rather than ``rcu_read_unlock_bh()``, but the
2402 RCU-bh read-side critical section executes during a time of heavy
2415 ``rcu_read_lock_bh_held()``. However, the update-side APIs are now
2424 single flavor. The read-side API remains, and continues to disable
2428 Before preemptible RCU, waiting for an RCU grace period had the side
2432 RCU read-side critical section can be a quiescent state. Therefore,
2442 preemption attempt during the RCU-sched read-side critical section,
2458 preemption also marks an RCU-sched read-side critical section, including
2466 read-side critical section” was a reliable indication that this someone
2468 read-side critical section, you can probably afford to use a
2470 the advent of the Linux kernel's notifiers, whose RCU read-side critical
2481 That said, one consequence of these domains is that read-side code must
2493 As noted above, it is legal to block within SRCU read-side critical
2495 block forever in one of a given domain's SRCU read-side critical
2498 happen if any operation in a given domain's SRCU read-side critical
2515 ``ss1``-domain SRCU read-side critical section acquired another mutex
2521 Unlike the other RCU flavors, SRCU read-side critical sections can run
2544 period has the side effect of expediting all prior grace periods that
2580 anywhere in the code, it is not possible to use read-side markers such
2594 RCU <https://lwn.net/Articles/607117/>`__, is to have implicit read-side
2598 userspace execution also delimit tasks-RCU read-side critical sections.
2612 One of the tricks that RCU uses to attain update-side scalability is to
2636 be unnecessary because the hotpath read-side primitives do not access