On Fri, 20 Mar 2009 18:27:46 -0700 "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote: > On Fri, Mar 20, 2009 at 11:13:54AM -0700, Arjan van de Ven wrote: > > On Fri, 20 Mar 2009 07:31:04 -0700 > > "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > that'd be throwing out the baby with the bathwater... I'm > > > > trying to use the other cpus to do some of the boot work (so > > > > that the total goes faster); not using the other cpus would be > > > > counter productive to that. (As is just sitting in > > > > synchronize_rcu() when the other cpu is working.. hence this > > > > discussion ;-) > > > > > > OK, so you are definitely running multiple CPUs when the offending > > > synchronize_rcu() executes, then? > > > > absolutely. > > (and I'm using bootgraph.pl in scripts to track who's stalling etc) > > > > > > If so, here are some follow-on questions: > > > > > > 1. How many synchronize_rcu() calls are you seeing on the > > > critical boot path > > > > I've seen only this (input) one to take a long time > > Ouch!!! A -single- synchronize_rcu() taking a full second??? That > indicates breakage. > > > > and what value of HZ are you running? > > > > 1000 > > K, in absence of readers for RCU_CLASSIC, we should see a handful > of milliseconds for synchronize_rcu(). I've attached an instrumented bootgraph of what is going on; the rcu delays are shown as red blocks inside the regular functions as they initialize...... (svg can be viewed with inkscape, gimp, firefox and various other tools) -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org
Attachment:
dmesg.svg
Description: image/svg
