Commit 3d916a44 authored by Paul E. McKenney's avatar Paul E. McKenney

documentation: Slow systems can stall RCU grace periods

If a fast system has a worst-case grace-period duration of (say) ten
seconds, then running the same workload on a system ten times as slow
will get you an RCU CPU stall warning given default stall-warning
timeout settings.  This commit therefore adds this possibility to
stallwarn.txt.
Reported-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
parent dfa0ee48
...@@ -70,6 +70,12 @@ o A periodic interrupt whose handler takes longer than the time ...@@ -70,6 +70,12 @@ o A periodic interrupt whose handler takes longer than the time
considerably longer than normal, which can in turn result in considerably longer than normal, which can in turn result in
RCU CPU stall warnings. RCU CPU stall warnings.
o Testing a workload on a fast system, tuning the stall-warning
timeout down to just barely avoid RCU CPU stall warnings, and then
running the same workload with the same stall-warning timeout on a
slow system. Note that thermal throttling and on-demand governors
can cause a single system to be sometimes fast and sometimes slow!
o A hardware or software issue shuts off the scheduler-clock o A hardware or software issue shuts off the scheduler-clock
interrupt on a CPU that is not in dyntick-idle mode. This interrupt on a CPU that is not in dyntick-idle mode. This
problem really has happened, and seems to be most likely to problem really has happened, and seems to be most likely to
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment