| /linux/Documentation/RCU/Design/Expedited-Grace-Periods/ |
| H A D | Expedited-Grace-Periods.rst | 8 This document describes RCU's expedited grace periods.
9 Unlike RCU's normal grace periods, which accept long latencies to attain
10 high efficiency and minimal disturbance, expedited grace periods accept
20 The expedited RCU grace periods cannot be accused of being subtle,
23 grace period.
24 The one saving grace is that the hammer has grown a bit smaller
32 state, the expedited grace period has completed.
43 expedited grace period is shown in the following diagram:
54 Otherwise, the expedited grace period will use
72 block the current expedited grace period until it resumes and finds its
[all …]
|
| /linux/Documentation/RCU/Design/Memory-Ordering/ |
| H A D | Tree-RCU-Memory-Ordering.rst | 13 grace-period memory ordering guarantee is provided.
18 RCU grace periods provide extremely strong memory-ordering guarantees
20 Any code that happens after the end of a given RCU grace period is guaranteed
21 to see the effects of all accesses prior to the beginning of that grace
23 Similarly, any code that happens before the beginning of a given RCU grace
25 of that grace period that are within RCU read-side critical sections.
34 two phases, one of which is executed before the grace period and
35 the other of which is executed after the grace period.
49 The workhorse for RCU's grace-period memory ordering is the
73 network among all CPUs that were in any way involved in the grace
[all …]
|
| /linux/Documentation/litmus-tests/rcu/ |
| H A D | RCU+sync+free.litmus | 7 * follows a grace period, if it did not see writes that precede that grace
10 * This is a typical pattern of RCU usage, where the write before the grace
11 * period assigns a pointer, and the writes following the grace period destroy
14 * This is one implication of the RCU grace-period guarantee, which says (among
15 * other things) that an RCU read-side critical section cannot span a grace period.
|
| H A D | RCU+sync+read.litmus | 6 * This litmus test demonstrates that after a grace period, an RCU updater always
8 * read-side critical sections would have ended before the grace period ended.
10 * This is one implication of the RCU grace-period guarantee, which says (among
11 * other things) that an RCU read-side critical section cannot span a grace period.
|
| /linux/Documentation/RCU/Design/Data-Structures/ |
| H A D | Data-Structures.rst | 20 to execute extremely quickly, while also processing the RCU grace periods
46 grace periods are completed at the tree's root ``rcu_node``
48 A grace period can be completed at the root once every CPU
51 Once a grace period has completed, record of that fact is propagated
102 and scalability benefits of partitioning, even though RCU grace-period
112 there are in the system, at most 64 quiescent-state reports per grace
121 RCU updaters wait for normal grace periods by registering RCU callbacks,
125 while they are waiting for a grace period to elapse, as shown in the
145 example, awareness of the start or end of a given RCU grace period
155 ``rcu_node`` and ``rcu_data`` structures, tracks grace periods,
[all …]
|
| /linux/Documentation/RCU/ |
| H A D | stallwarn.rst | 40 - Anything that prevents RCU's grace-period kthreads from running.
51 in which case the next RCU grace period can never complete, which
60 RCU grace periods from ever completing. Either way, the
127 Please note that RCU only detects CPU stalls when there is a grace period
128 in progress. No grace period, no CPU stall warnings.
147 CPU stall detector, which detects conditions that unduly delay RCU grace
157 that RCU will wait from the beginning of a grace period until it
177 the expedited grace period. This parameter defines the period
179 grace period until it issues an RCU CPU stall warning. This time
225 task stalling the current RCU-tasks grace period.
[all …]
|
| H A D | rcu.rst | 9 A "grace period" must elapse between the two parts, and this grace period
13 a grace period to elapse, then free the element. See listRCU.rst for more
29 - How can the updater tell when a grace period has completed
46 critical sections. These variants of RCU detect grace periods
50 thing at a time, why should I wait for a grace period?
|
| H A D | rcubarrier.rst | 9 a grace period to elapse. This primitive takes a pointer to an rcu_head
41 grace period to elapse, it does not wait for the callbacks to complete.
55 than waiting for a grace period to elapse, rcu_barrier() waits for all
59 immediately, without waiting for anything, let alone a grace period.
269 are delayed for a full grace period? Couldn't this result in
322 the corresponding grace period elapsed, all before CPU 1's
331 section, thus preventing CPU 0's grace period from completing
350 are delayed for a full grace period? Couldn't this result in
359 a grace period from completing on non-CONFIG_PREEMPTION kernels,
361 state) before the grace period can complete. However, this is
[all …]
|
| H A D | UP.rst | 23 after a grace period.
45 RCU usage, since call_rcu() must wait for a grace period to elapse.
63 call_rcu() invocation a full grace period later.
91 grace period has elapsed since those callbacks were queued. This is
102 infrastructure *must* respect grace periods, and *must* invoke callbacks
151 end of the grace period, which would come as a nasty shock to
|
| H A D | checklist.rst | 61 to prevent grace periods from ending prematurely, which
223 kernel boot parameter to completely disable expedited grace
247 srcu_struct. The rules for the expedited RCU grace-period-wait
291 primitive is that it automatically self-limits: if grace periods
295 cases where grace periods are delayed, as failing to do so can
303 those waiting for a grace period to elapse. Enforce a
311 spinning on the lock could prevent the grace period
316 RCU grace period. There are of course many other
332 number of updates per grace period.
442 Second, grace-period-detection overhead is amortized only
[all …]
|
| H A D | rculist_nulls.rst | 47 * reuse these object before the RCU grace period, we
125 very very fast (before the end of RCU grace period)
|
| /linux/Documentation/filesystems/ |
| H A D | quota.rst | 13 softlimit but only for limited period of time. This period is called "grace
14 period" or "grace time". When grace time is over, user is not able to allocate
17 Quota limits (and amount of grace time) are set independently for each
25 When user exceeds a softlimit, runs out of grace time or reaches hardlimit,
59 than given grace period
66 longer than given grace period.
|
| /linux/Documentation/RCU/Design/Requirements/ |
| H A D | Requirements.rst | 67 RCU's grace-period guarantee is unusual in being premeditated: Jack
73 RCU's grace-period guarantee allows updaters to wait for the completion
185 | Without that extra grace period, memory reordering could result in |
196 Although RCU's grace-period guarantee is useful in and of itself, with
199 data structures. For this, the grace-period guarantee is not sufficient,
415 This function is straightforward, with line 13 waiting for a grace
460 can be used in combination with the grace-period guarantee to also allow
531 | code, why does it matter how it relates to a grace period?” The |
535 | preceding and following the grace period. If we take this viewpoint, |
537 | grace period when some access preceding the grace period observes the |
[all …]
|
| /linux/kernel/rcu/ |
| H A D | Kconfig.debug | 88 bool "Log grace-period numbers for rcutorture failures"
94 corresponding grace-period sequence numbers. This information
98 Say Y here if you want grace-period sequence numbers logged.
122 If a given RCU grace period extends more than the specified
124 RCU grace period persists, additional CPU stall warnings are
133 If a given expedited RCU grace period extends more than the
135 If the RCU grace period persists, additional CPU stall warnings
202 bool "Provide debug RCU implementation with short grace periods"
208 grace periods, making them as short as it can. This limits
225 but it also increases the probability of extending grace period
|
| H A D | Kconfig | 216 number of cache misses incurred during RCU's grace-period
240 block the current preemptible RCU grace period for too long.
248 int "Milliseconds to delay boosting after RCU grace-period start"
254 a given grace period before priority-boosting preempted RCU
255 readers blocking that grace period. Note that any RCU reader
256 blocking an expedited RCU grace period is boosted immediately.
266 grace periods at the expense of being more disruptive.
269 disable expedited grace periods after boot by unconditionally
296 online), which handles grace periods for its group. Nothing
345 corresponding grace period for multiple seconds. The grace
|
| /linux/fs/nfs_common/ |
| H A D | Makefile | 13 obj-$(CONFIG_GRACE_PERIOD) += grace.o
|
| /linux/Documentation/litmus-tests/ |
| H A D | README | 79 Both the above litmus tests demonstrate the RCU grace period guarantee
80 that an RCU read-side critical section can never span a grace period.
|
| /linux/Documentation/filesystems/nfs/ |
| H A D | reexport.rst | 30 rebooted, and so it is not in grace. Since the source server is not in
31 grace, it cannot offer any guarantees that the file won't have been
|
| /linux/tools/memory-model/Documentation/ |
| H A D | simple.txt | 62 takes this approach for much of its grace-period processing and also
64 single-threaded grace-period processing is use of batching, where all
65 updates that accumulated during one grace period are handled by the
66 next one. In other words, slowing down grace-period processing makes
128 locking to report quiescent states up the grace-period combining tree.
|
| H A D | explanation.txt | 930 grace periods obey the rules of RCU, in particular, the
1517 rests on two concepts: grace periods and read-side critical sections.
1519 A grace period is the span of time occupied by a call to
1527 span a full grace period. In more detail, the Guarantee says:
1529 For any critical section C and any grace period G, at least
1541 before and end after a grace period.
1568 P1's grace period, contrary to part (2) of the Guarantee. On the
1571 the grace period, contrary to part (1). Together the results violate
1577 starts before a grace period does then the critical section's CPU will
1579 some time before the grace period's synchronize_rcu() call returns.
[all …]
|
| /linux/Documentation/admin-guide/nfs/ |
| H A D | nfsd-admin-interfaces.rst | 25 On startup, nfsd and lockd grace periods start. nfsd is shut down by a write of
|
| /linux/tools/testing/selftests/rcutorture/bin/ |
| H A D | kvm.sh | 253 --shutdown-grace)
254 checkarg --shutdown-grace "(seconds)" "$#" "$2" '^[0-9]*$' '^error'
|
| /linux/fs/xfs/ |
| H A D | xfs_dquot.h | 238 time64_t xfs_dquot_set_grace_period(time64_t grace);
|
| /linux/Documentation/core-api/ |
| H A D | assoc_array.rst | 82 after an RCU grace period has passed - thus allowing access functions to
160 Free the specified object. Note that this may be called an RCU grace period
520 until after the RCU grace period.
524 after the RCU grace period.
562 Obsolete blocks and leaves are freed up after an RCU grace period has passed,
|
| /linux/fs/lockd/ |
| H A D | svc.c | 102 static void grace_ender(struct work_struct *grace) in grace_ender() argument
104 struct delayed_work *dwork = to_delayed_work(grace); in grace_ender()
|