Thread (45 messages) 45 messages, 7 authors, 2012-10-01

rcu self-detected stall messages on OMAP3, 4 boards

From: paul@pwsan.com (Paul Walmsley)
Date: 2012-09-22 18:42:10
Also in: linux-omap, lkml

On Fri, 21 Sep 2012, Paul E. McKenney wrote:
Could you please point me to a recipe for creating a minimal userspace?
Just in case it is the userspac erather than the architecture/hardware
that makes the difference.
Tony's suggestion is pretty good.  Note that there may also be differences 
in kernel timers -- either between x86 and ARM architectures, or loaded 
device drivers -- that may confound the problem.
Just to make sure I understand the combinations:

o	All stalls have happened when running a minimal userspace.
o	CONFIG_NO_HZ=n suppresses the stalls.
o	CONFIG_RCU_FAST_NO_HZ (which depends on CONFIG_NO_HZ=y) has
	no observable effect on the stalls.

Did I get that right, or am I missing a combination?
That's correct.
Indeed, rcu_idle_gp_timer_func() is a bit strange in that it is 
cancelled upon exit from idle, and therefore should (almost) never 
actually execute. Its sole purpose is to wake up the CPU.  ;-)
Right.  Just curious, what would wake up the kernel from idle to handle a 
grace period expiration when CONFIG_RCU_FAST_NO_HZ=n?  On a very idle 
system, the time between timer ticks could potentially be several tens of 
seconds.


- Paul
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help