/linux-6.3-rc2/Documentation/RCU/Design/Expedited-Grace-Periods/ |
A D | Expedited-Grace-Periods.rst | 8 This document describes RCU's expedited grace periods. 23 grace period. 32 state, the expedited grace period has completed. 54 Otherwise, the expedited grace period will use 75 the CPU is no longer blocking the grace period. 251 If each grace-period request was carried out separately, expedited grace 270 grace period. 420 previous grace period's wakeups complete before the next grace period's 436 stalls just as normal grace periods do. 448 | grace period in progress, in which case the normal grace period | [all …]
|
/linux-6.3-rc2/Documentation/RCU/Design/Memory-Ordering/ |
A D | Tree-RCU-Memory-Ordering.rst | 13 grace-period memory ordering guarantee is provided. 35 the other of which is executed after the grace period. 49 The workhorse for RCU's grace-period memory ordering is the 75 the grace period in question. 198 newly arrived RCU callbacks against future grace periods: 382 grace period. 388 | see the start of the grace period right when it started that grace | 429 grace period, and thus a critical section that the grace period must 518 grace period. 573 cleanup is complete, the next grace period can begin. [all …]
|
/linux-6.3-rc2/Documentation/litmus-tests/rcu/ |
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.
|
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-6.3-rc2/Documentation/RCU/Design/Data-Structures/ |
A D | Data-Structures.rst | 159 states when grace periods extend too long, 172 ignored during a given grace period. 393 beginning and the end of each grace period. 437 current expedited grace period. An expedited grace period has the same 446 expedited grace periods, respectively. 509 grace period. That pointer is stored in ``->gp_tasks`` for normal grace 529 normal grace period, and task T3 is blocking neither grace period. Note 536 grace period is waiting on a blocked task. 699 grace period. 902 each grace period. [all …]
|
/linux-6.3-rc2/Documentation/RCU/ |
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 121 in progress. No grace period, no CPU stall warnings. 150 that RCU will wait from the beginning of a grace period until it 170 the expedited grace period. This parameter defines the period 172 grace period until it issues an RCU CPU stall warning. This time 218 task stalling the current RCU-tasks grace period. 249 interrupts during the current stalled grace period. 264 (stalled) grace period, or it might be some earlier grace period (for [all …]
|
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?
|
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 353 are delayed for a full grace period? Couldn't this result in 362 a grace period from completing on non-CONFIG_PREEMPTION kernels, 364 state) before the grace period can complete. However, this is [all …]
|
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
|
A D | checklist.rst | 61 to prevent grace periods from ending prematurely, which 217 kernel boot parameter to completely disable expedited grace 282 cases where grace periods are delayed, as failing to do so can 290 those waiting for a grace period to elapse. Enforce a 298 spinning on the lock could prevent the grace period 303 RCU grace period. There are of course many other 319 number of updates per grace period. 426 Second, grace-period-detection overhead is amortized only 482 (or friends) before an RCU grace period has elapsed 514 to wait for a grace period. For example, if there are no [all …]
|
A D | rculist_nulls.rst | 36 * reuse these object before the RCU grace period, we 114 very very fast (before the end of RCU grace period)
|
/linux-6.3-rc2/Documentation/filesystems/ |
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-6.3-rc2/Documentation/RCU/Design/Requirements/ |
A D | Requirements.rst | 537 | grace period when some access preceding the grace period observes the | 861 manner, it is necessary to use two grace periods, where the first grace 918 happens between a pair of grace periods, then those grace periods cannot 973 given grace period, just so long as it does not overlap the entire grace 975 a pair of RCU grace periods. 1472 grace period. 1576 grace-period processing. This evasive action causes the grace period to 1891 to wait for a grace period. 2565 an SRCU grace period, that grace period is waiting on a timer, and that 2607 that this grace period will be started. [all …]
|
/linux-6.3-rc2/kernel/rcu/ |
A D | Kconfig.debug | 77 If a given RCU grace period extends more than the specified 79 RCU grace period persists, additional CPU stall warnings are 88 If a given expedited RCU grace period extends more than the 90 If the RCU grace period persists, additional CPU stall warnings 132 bool "Provide debug RCU implementation with short grace periods" 138 grace periods, making them as short as it can. This limits
|
A D | Kconfig | 179 number of cache misses incurred during RCU's grace-period 203 block the current preemptible RCU grace period for too long. 211 int "Milliseconds to delay boosting after RCU grace-period start" 217 a given grace period before priority-boosting preempted RCU 218 readers blocking that grace period. Note that any RCU reader 219 blocking an expedited RCU grace period is boosted immediately. 229 grace periods at the expense of being more disruptive. 232 disable expedited grace periods after boot by unconditionally 301 RCU grace periods. Given that a reasonable setting of
|
/linux-6.3-rc2/Documentation/litmus-tests/ |
A 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.
|
/linux-6.3-rc2/fs/nfs_common/ |
A D | Makefile | 9 obj-$(CONFIG_GRACE_PERIOD) += grace.o
|
/linux-6.3-rc2/drivers/firewire/ |
A 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()
|
/linux-6.3-rc2/tools/memory-model/Documentation/ |
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.
|
A D | explanation.txt | 929 grace periods obey the rules of RCU, in particular, the 1518 A grace period is the span of time occupied by a call to 1526 span a full grace period. In more detail, the Guarantee says: 1528 For any critical section C and any grace period G, at least 1540 before and end after a grace period. 1606 and that event is a synchronize_rcu() fence (i.e., a grace 1714 the end of the grace period. 1722 relation, and R is po-before the grace period S. Thus we have: 1777 because S is a grace period. 1849 grace period does and ends after it does. [all …]
|
/linux-6.3-rc2/Documentation/admin-guide/nfs/ |
A D | nfsd-admin-interfaces.rst | 25 On startup, nfsd and lockd grace periods start. nfsd is shut down by a write of
|
/linux-6.3-rc2/fs/xfs/ |
A D | xfs_dquot.h | 243 time64_t xfs_dquot_set_grace_period(time64_t grace);
|
/linux-6.3-rc2/tools/testing/selftests/rcutorture/bin/ |
A D | kvm.sh | 233 --shutdown-grace) 234 checkarg --shutdown-grace "(seconds)" "$#" "$2" '^[0-9]*$' '^error'
|
/linux-6.3-rc2/fs/lockd/ |
A D | svc.c | 95 static void grace_ender(struct work_struct *grace) in grace_ender() argument 97 struct delayed_work *dwork = to_delayed_work(grace); in grace_ender()
|
/linux-6.3-rc2/tools/memory-model/ |
A D | linux-kernel.cat | 125 * Any sequence containing at least as many grace periods as RCU read-side 128 * Likewise for SRCU grace periods and read-side critical sections, provided
|