/kernel/linux/linux-5.10/Documentation/RCU/Design/Expedited-Grace-Periods/ |
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 …]
|
/kernel/linux/linux-5.10/Documentation/RCU/Design/Memory-Ordering/ |
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 …]
|
/kernel/linux/linux-5.10/Documentation/litmus-tests/rcu/ |
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.
|
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.
|
/kernel/linux/linux-5.10/Documentation/RCU/ |
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 107 RCU only detects CPU stalls when there is a grace period in progress. 108 No grace period, no CPU stall warnings. 127 CPU stall detector, which detects conditions that unduly delay RCU grace 137 that RCU will wait from the beginning of a grace period until it 184 task stalling the current RCU-tasks grace period. 207 the RCU core for the past three grace periods. In contrast, CPU 16's "(0 209 interrupts during the current stalled grace period. [all …]
|
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 the 30 - How can the updater tell when a grace period has completed 47 critical sections. These variants of RCU detect grace periods 51 thing at a time, why should I wait for a grace period?
|
D | rcubarrier.rst | 66 grace period to elapse, it does not wait for the callbacks to complete. 79 a grace period to elapse, rcu_barrier() waits for all outstanding RCU 83 without waiting for a grace period to elapse. 276 are delayed for a full grace period? Couldn't this result in 324 are delayed for a full grace period? Couldn't this result in 332 a grace period from completing on non-CONFIG_PREEMPT kernels, 334 state) before the grace period can complete. However, this is 340 switching, again preventing grace periods from completing. This
|
D | checklist.rst | 61 to prevent grace periods from ending prematurely, which 204 boot parameter to completely disable expedited grace periods, 249 primitive is that it automatically self-limits: if grace periods 253 cases where grace periods are delayed, as failing to do so can 261 those waiting for a grace period to elapse. Enforce a 269 spinning on the lock could prevent the grace period 274 RCU grace period. There are of course many other 290 number of updates per grace period. 376 Second, grace-period-detection overhead is amortized only 428 grace period has elapsed since the last time that you [all …]
|
D | UP.rst | 23 after a grace period. 45 RCU usage, since call_rcu() must wait for a grace period to elapse. 93 infrastructure *must* respect grace periods, and *must* invoke callbacks 142 end of the grace period, which would come as a nasty shock to
|
D | rculist_nulls.rst | 36 * reuse these object before the RCU grace period, we 117 very very fast (before the end of RCU grace period)
|
D | torture.rst | 96 incremented once per grace period subsequently -- and is freed 97 after passing through (RCU_TORTURE_PIPE_LEN-2) grace periods. 105 than in terms of grace periods. The legal number of non-zero 115 passes through a grace period. The last entry should be zero,
|
/kernel/linux/linux-5.10/Documentation/RCU/Design/Data-Structures/ |
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 …]
|
/kernel/linux/linux-5.10/Documentation/filesystems/ |
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.
|
/kernel/linux/linux-5.10/kernel/rcu/ |
D | Kconfig | 154 number of cache misses incurred during RCU's grace-period 173 bool "Accelerate last non-dyntick-idle CPU's grace periods" 182 hand, this option increases the duration of RCU grace periods, 186 don't care about increased grace-period durations. 196 block the current preemptible RCU grace period for too long. 204 int "Milliseconds to delay boosting after RCU grace-period start" 210 a given grace period before priority-boosting preempted RCU 211 readers blocking that grace period. Note that any RCU reader 212 blocking an expedited RCU grace period is boosted immediately. 247 RCU grace periods. Given that a reasonable setting of
|
D | Kconfig.debug | 89 If a given RCU grace period extends more than the specified 91 RCU grace period persists, additional CPU stall warnings are 118 bool "Provide debug RCU implementation with short grace periods" 124 grace periods, making them as short as it can. This limits
|
/kernel/linux/linux-5.10/Documentation/RCU/Design/Requirements/ |
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, 414 This function is straightforward, with line 13 waiting for a grace 459 can be used in combination with the grace-period guarantee to also allow 530 | code, why does it matter how it relates to a grace period?” The | 534 | preceding and following the grace period. If we take this viewpoint, | 536 | grace period when some access preceding the grace period observes the | [all …]
|
/kernel/linux/linux-5.10/Documentation/litmus-tests/ |
D | README | 34 Both the above litmus tests demonstrate the RCU grace period guarantee 35 that an RCU read-side critical section can never span a grace period.
|
/kernel/linux/linux-5.10/fs/nfs_common/ |
D | Makefile | 9 obj-$(CONFIG_GRACE_PERIOD) += grace.o
|
/kernel/linux/linux-5.10/tools/testing/selftests/rcutorture/bin/ |
D | kvm.sh | 195 --shutdown-grace) 196 checkarg --shutdown-grace "(seconds)" "$#" "$2" '^[0-9]*$' '^error'
|
/kernel/linux/linux-5.10/drivers/firewire/ |
D | core-card.c | 293 int gap_count, generation, grace, rcode; in bm_work() local 329 grace = time_after64(get_jiffies_64(), in bm_work() 334 (card->bm_generation != generation && grace)) { in bm_work()
|
/kernel/linux/linux-5.10/tools/memory-model/Documentation/ |
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.
|
D | explanation.txt | 877 grace periods obey the rules of RCU, in particular, the 1434 rests on two concepts: grace periods and read-side critical sections. 1436 A grace period is the span of time occupied by a call to 1444 span a full grace period. In more detail, the Guarantee says: 1446 For any critical section C and any grace period G, at least 1458 before and end after a grace period. 1485 P1's grace period, contrary to part (2) of the Guarantee. On the 1488 the grace period, contrary to part (1). Together the results violate 1494 starts before a grace period does then the critical section's CPU will 1496 some time before the grace period's synchronize_rcu() call returns. [all …]
|
/kernel/linux/linux-5.10/Documentation/admin-guide/nfs/ |
D | nfsd-admin-interfaces.rst | 25 On startup, nfsd and lockd grace periods start. nfsd is shut down by a write of
|
/kernel/linux/linux-5.10/fs/xfs/ |
D | xfs_dquot.h | 241 time64_t xfs_dquot_set_grace_period(time64_t grace);
|
/kernel/linux/linux-5.10/fs/lockd/ |
D | svc.c | 99 static void grace_ender(struct work_struct *grace) in grace_ender() argument 101 struct delayed_work *dwork = to_delayed_work(grace); in grace_ender()
|