diff options
| author | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | 2011-06-08 15:51:57 -0700 |
|---|---|---|
| committer | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | 2011-06-21 23:21:28 -0700 |
| commit | d4989e0ba215099b24155bc8ae85080d3d7e4a4c (patch) | |
| tree | c63eb0abcdbf2334c431aa162750ac977aec21b3 /Documentation | |
| parent | 5077cd2b045140f03da879fcad91360d18d9071d (diff) | |
rcu: Avoid grace-period overflow for long dyntick-idle periods
In 32-bit kernels, if a given CPU is in dyntick-idle mode, its idea
of the current grace period will become out of date. If it stays in
dyntick-idle mode for too long the grace period will come back around
to that CPU's old value, which can cause interesting and quite fatal
failure modes. The time required for this too happen is measured in
weeks, so it needs to be dealt with, especially given the appearance of
multiprocessor battery-powered devices that might reasonably keep some
of the CPUs in dyntick-idle state for as long as the user isn't carrying
out some CPU-intensive task.
The idea is to check a given CPU at the start of each grace period.
If that CPU is online and the grace-period counter is more than half
way to overflow, kick the CPU.
In 64-bit kernels, the time required to overflow even assuming 500
grace periods per second is more than 500 million years. So 64-bit
kernels blithely ignore this possibility.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/RCU/trace.txt | 9 |
1 files changed, 7 insertions, 2 deletions
diff --git a/Documentation/RCU/trace.txt b/Documentation/RCU/trace.txt index a67af0a39ded..b9e26d66c27b 100644 --- a/Documentation/RCU/trace.txt +++ b/Documentation/RCU/trace.txt @@ -240,12 +240,12 @@ o "gpnum" is the number of grace periods that have started. It is The output of "cat rcu/rcuhier" looks as follows, with very long lines: -c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6 +c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6 doc=2 1/1 ..>. 0:127 ^0 3/3 ..>. 0:35 ^0 0/0 ..>. 36:71 ^1 0/0 ..>. 72:107 ^2 0/0 ..>. 108:127 ^3 3/3f ..>. 0:5 ^0 2/3 ..>. 6:11 ^1 0/0 ..>. 12:17 ^2 0/0 ..>. 18:23 ^3 0/0 ..>. 24:29 ^4 0/0 ..>. 30:35 ^5 0/0 ..>. 36:41 ^0 0/0 ..>. 42:47 ^1 0/0 ..>. 48:53 ^2 0/0 ..>. 54:59 ^3 0/0 ..>. 60:65 ^4 0/0 ..>. 66:71 ^5 0/0 ..>. 72:77 ^0 0/0 ..>. 78:83 ^1 0/0 ..>. 84:89 ^2 0/0 ..>. 90:95 ^3 0/0 ..>. 96:101 ^4 0/0 ..>. 102:107 ^5 0/0 ..>. 108:113 ^0 0/0 ..>. 114:119 ^1 0/0 ..>. 120:125 ^2 0/0 ..>. 126:127 ^3 rcu_bh: -c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0 +c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0 doc=3 0/1 ..>. 0:127 ^0 0/3 ..>. 0:35 ^0 0/0 ..>. 36:71 ^1 0/0 ..>. 72:107 ^2 0/0 ..>. 108:127 ^3 0/3f ..>. 0:5 ^0 0/3 ..>. 6:11 ^1 0/0 ..>. 12:17 ^2 0/0 ..>. 18:23 ^3 0/0 ..>. 24:29 ^4 0/0 ..>. 30:35 ^5 0/0 ..>. 36:41 ^0 0/0 ..>. 42:47 ^1 0/0 ..>. 48:53 ^2 0/0 ..>. 54:59 ^3 0/0 ..>. 60:65 ^4 0/0 ..>. 66:71 ^5 0/0 ..>. 72:77 ^0 0/0 ..>. 78:83 ^1 0/0 ..>. 84:89 ^2 0/0 ..>. 90:95 ^3 0/0 ..>. 96:101 ^4 0/0 ..>. 102:107 ^5 0/0 ..>. 108:113 ^0 0/0 ..>. 114:119 ^1 0/0 ..>. 120:125 ^2 0/0 ..>. 126:127 ^3 @@ -284,6 +284,11 @@ o "fqlh" is the number of calls to force_quiescent_state() that exited immediately (without even being counted in nfqs above) due to contention on ->fqslock. +o "dovf" is the ID of the next CPU to be checked for dyntick-idle + grace-period overflow. + + This field is displayed only for CONFIG_NO_HZ kernels. + o Each element of the form "1/1 0:127 ^0" represents one struct rcu_node. Each line represents one level of the hierarchy, from root to leaves. It is best to think of the rcu_data structures |