|
|
@@ -12,12 +12,12 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
|
|
|
This kernel configuration parameter defines the period of time
|
|
|
that RCU will wait from the beginning of a grace period until it
|
|
|
issues an RCU CPU stall warning. This time period is normally
|
|
|
- sixty seconds.
|
|
|
+ 21 seconds.
|
|
|
|
|
|
This configuration parameter may be changed at runtime via the
|
|
|
/sys/module/rcutree/parameters/rcu_cpu_stall_timeout, however
|
|
|
this parameter is checked only at the beginning of a cycle.
|
|
|
- So if you are 30 seconds into a 70-second stall, setting this
|
|
|
+ So if you are 10 seconds into a 40-second stall, setting this
|
|
|
sysfs parameter to (say) five will shorten the timeout for the
|
|
|
-next- stall, or the following warning for the current stall
|
|
|
(assuming the stall lasts long enough). It will not affect the
|
|
|
@@ -32,7 +32,7 @@ CONFIG_RCU_CPU_STALL_VERBOSE
|
|
|
also dump the stacks of any tasks that are blocking the current
|
|
|
RCU-preempt grace period.
|
|
|
|
|
|
-RCU_CPU_STALL_INFO
|
|
|
+CONFIG_RCU_CPU_STALL_INFO
|
|
|
|
|
|
This kernel configuration parameter causes the stall warning to
|
|
|
print out additional per-CPU diagnostic information, including
|
|
|
@@ -43,7 +43,8 @@ RCU_STALL_DELAY_DELTA
|
|
|
Although the lockdep facility is extremely useful, it does add
|
|
|
some overhead. Therefore, under CONFIG_PROVE_RCU, the
|
|
|
RCU_STALL_DELAY_DELTA macro allows five extra seconds before
|
|
|
- giving an RCU CPU stall warning message.
|
|
|
+ giving an RCU CPU stall warning message. (This is a cpp
|
|
|
+ macro, not a kernel configuration parameter.)
|
|
|
|
|
|
RCU_STALL_RAT_DELAY
|
|
|
|
|
|
@@ -52,7 +53,8 @@ RCU_STALL_RAT_DELAY
|
|
|
However, if the offending CPU does not detect its own stall in
|
|
|
the number of jiffies specified by RCU_STALL_RAT_DELAY, then
|
|
|
some other CPU will complain. This delay is normally set to
|
|
|
- two jiffies.
|
|
|
+ two jiffies. (This is a cpp macro, not a kernel configuration
|
|
|
+ parameter.)
|
|
|
|
|
|
When a CPU detects that it is stalling, it will print a message similar
|
|
|
to the following:
|
|
|
@@ -86,7 +88,12 @@ printing, there will be a spurious stall-warning message:
|
|
|
|
|
|
INFO: rcu_bh_state detected stalls on CPUs/tasks: { } (detected by 4, 2502 jiffies)
|
|
|
|
|
|
-This is rare, but does happen from time to time in real life.
|
|
|
+This is rare, but does happen from time to time in real life. It is also
|
|
|
+possible for a zero-jiffy stall to be flagged in this case, depending
|
|
|
+on how the stall warning and the grace-period initialization happen to
|
|
|
+interact. Please note that it is not possible to entirely eliminate this
|
|
|
+sort of false positive without resorting to things like stop_machine(),
|
|
|
+which is overkill for this sort of problem.
|
|
|
|
|
|
If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
|
|
|
more information is printed with the stall-warning message, for example:
|
|
|
@@ -216,4 +223,5 @@ that portion of the stack which remains the same from trace to trace.
|
|
|
If you can reliably trigger the stall, ftrace can be quite helpful.
|
|
|
|
|
|
RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE
|
|
|
-and with RCU's event tracing.
|
|
|
+and with RCU's event tracing. For information on RCU's event tracing,
|
|
|
+see include/trace/events/rcu.h.
|
Paul E. McKenney