summaryrefslogtreecommitdiffstats
path: root/lib/ts_bm.c
diff options
context:
space:
mode:
authorPaul E. McKenney <paulmck@linux.vnet.ibm.com>2008-08-10 18:35:38 -0700
committerIngo Molnar <mingo@elte.hu>2008-08-11 13:35:18 +0200
commit67182ae1c42206e516f7efb292b745e826497b24 (patch)
treed2d402550a0432489090264df95a8154597dc989 /lib/ts_bm.c
parentc4c0c56a7a85ed5725786219e4fbca7e840b1531 (diff)
downloadop-kernel-dev-67182ae1c42206e516f7efb292b745e826497b24.zip
op-kernel-dev-67182ae1c42206e516f7efb292b745e826497b24.tar.gz
rcu, debug: detect stalled grace periods
this is a diagnostic patch for Classic RCU. The approach is to record a timestamp at the beginning of the grace period (in rcu_start_batch()), then have rcu_check_callbacks() complain if: 1. it is running on a CPU that has holding up grace periods for a long time (say one second). This will identify the culprit assuming that the culprit has not disabled hardware irqs, instruction execution, or some such. 2. it is running on a CPU that is not holding up grace periods, but grace periods have been held up for an even longer time (say two seconds). It is enabled via the default-off CONFIG_DEBUG_RCU_STALL kernel parameter. Rather than exponential backoff, it backs off to once per 30 seconds. My feeling upon thinking on it was that if you have stalled RCU grace periods for that long, a few extra printk() messages are probably the least of your worries... Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Yinghai Lu <yhlu.kernel@gmail.com> Cc: David Witbrodt <dawitbro@sbcglobal.net> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'lib/ts_bm.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud