Lines Matching refs: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
370 outermost RCU read-side critical section containing that
387 #. Wait for all pre-existing RCU read-side critical sections to complete
427 read-side critical section or in a code segment where the pointer
429 update-side lock.
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 |
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 |
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 |
606 | read-side critical sections are done? Won't the compiler |
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 |
654 within an RCU read-side critical section. For example, that RCU
655 read-side critical section might search for a given data element, and
656 then might acquire the update-side spinlock in order to update that
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
674 This guarantee allows lookup code to be shared between read-side and
675 update-side code, and was premeditated, appearing in the earliest
681 RCU provides extremely lightweight readers, and its read-side
698 Reader-side markers such as rcu_read_lock() and
812 It is tempting to assume that if any part of one RCU read-side critical
814 read-side critical section follows that same grace period, then all of
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
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
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
981 | read-side critical section, would be required to partition the RCU |
982 | read-side critical sections at the beginning and end of the chain? |
1063 situations, which means that RCU's read-side primitives are optimized,
1064 often at the expense of its update-side primitives. Experience thus far
1077 b. Wait-free read-side primitives for real-time use.
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 |
1099 | read-side critical sections, and also within Linux-kernel sleepable |
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 |
1157 within the RCU read-side critical section, and this is indicated by the
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.
1230 microseconds on small systems, at least in cases where the RCU read-side
1421 example, an infinite loop in an RCU read-side critical section must by
1449 has been preempted within an RCU read-side critical section is
1495 use. And in theory, RCU read-side critical sections may be composed, and
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
1534 In short, although RCU read-side critical sections are highly
1542 read-side critical sections, perhaps even so intense that there was
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
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
1563 rates should not delay RCU read-side critical sections, although some
1564 small read-side delays can occur when using
1589 splat if rcu_dereference() is used outside of an RCU read-side
1590 critical section. Update-side code can use
1602 that it has been invoked within an RCU read-side critical section. I
1629 #. An infinite loop in an RCU read-side critical section will eventually
1635 waiting on that particular RCU read-side critical section.
1654 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 RCU_>`__ read-side
1988 somewhere within the corresponding RCU read-side critical section.
1995 read-side critical sections implicitly avoids earlier issues that used
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.
2073 RCU read-side critical section on an idle CPU. (Kernels built with
2077 whether or not it is currently legal to run RCU read-side critical
2188 #. If a CPU is in a portion of the kernel that executes RCU read-side
2194 no-joking guaranteed to never execute any RCU read-side critical
2203 fact joking about not doing RCU read-side critical sections.
2301 read-side primitives. To that end, it would be good if preemptible RCU's
2324 approach of disabling preemption across RCU read-side critical sections
2326 an RCU implementation that allows RCU read-side critical sections to be
2400 single flavor. The read-side API remains, and continues to disable
2415 local_bh_disable() across its read-side critical sections, and which
2425 during the RCU-bh read-side critical section will be deferred. In this
2429 read-side critical section rather than rcu_read_unlock_bh(), but the
2432 RCU-bh read-side critical section executes during a time of heavy
2443 old RCU-bh update-side APIs are now gone, replaced by synchronize_rcu(),
2445 anything that disables bottom halves also marks an RCU-bh read-side
2454 single flavor. The read-side API remains, and continues to disable
2458 Before preemptible RCU, waiting for an RCU grace period had the side
2462 RCU read-side critical section can be a quiescent state. Therefore,
2472 preemption attempt during the RCU-sched read-side critical section,
2485 rcu_read_lock_sched_held(). However, the old RCU-sched update-side APIs
2488 preemption also marks an RCU-sched read-side critical section,
2496 read-side critical section” was a reliable indication that this someone
2498 read-side critical section, you can probably afford to use a
2500 the advent of the Linux kernel's notifiers, whose RCU read-side critical
2511 That said, one consequence of these domains is that read-side code must
2523 As noted above, it is legal to block within SRCU read-side critical
2525 block forever in one of a given domain's SRCU read-side critical
2528 happen if any operation in a given domain's SRCU read-side critical
2545 ``ss1``-domain SRCU read-side critical section acquired another mutex
2551 Unlike the other RCU flavors, SRCU read-side critical sections can run
2574 period has the side effect of expediting all prior grace periods that
2628 anywhere in the code, it is not possible to use read-side markers such
2642 RCU <https://lwn.net/Articles/607117/>`__, is to have implicit read-side
2646 userspace execution also delimit tasks-RCU read-side critical sections.
2660 One of the tricks that RCU uses to attain update-side scalability is to
2684 be unnecessary because the hotpath read-side primitives do not access