lkml.org 
[lkml]   [2009]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Question about usage of RCU in the input layer
    On Fri, Mar 20, 2009 at 07:31:04AM -0700, Paul E. McKenney wrote:
    > On Fri, Mar 20, 2009 at 06:50:58AM -0700, Arjan van de Ven wrote:
    > > On Thu, 19 Mar 2009 21:45:41 -0700
    > > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
    > >
    > > > > single CPU is soooo last decade ;-)
    > > > > But seriously I no longer have systems that aren't dual core or SMT
    > > > > in some form...
    > > >
    > > > OK, I will ask the stupid question...
    > > >
    > > > Why not delay bringing up the non-boot CPUs until later in boot?
    > >
    > > 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?
    >
    > If so, here are some follow-on questions:
    >
    > 1. How many synchronize_rcu() calls are you seeing on the
    > critical boot path and what value of HZ are you running?
    >
    > If each synchronize_rcu() is taking (say) tens of jiffies, then,
    > as Peter Zijlstra notes earlier in this thread, we need to focus
    > on what is taking too long to get through its RCU read-side
    > critical sections. Otherwise, if each synchronize_rcu() is
    > in the 3-5 jiffy range, I may finally be forced to create an
    > expedited version of the synchronize_rcu() API.
    >
    > 2. If expediting is required, then the code calling synchronize_rcu()
    > might or might not have any idea whether or not expediting is
    > appropriate. If it does not, then we would need some sort of way
    > to tell synchronize_rcu() that it should act more aggressively,
    > perhaps /proc flag or kernel global variable indicating that
    > boot is in progress.
    >
    > No, we do not want to make synchronize_rcu() aggressive all the
    > time, as this would harm performance and energy efficiency in
    > the normal runtime situation.
    >
    > So, if it turns out that synchronize_rcu()'s caller does not
    > know whether or not expediting is appropriate, can the boot path
    > manipulate such a flag or variable?
    >
    > 3. Which RCU implementation are you using? CONFIG_CLASSIC_RCU,
    > CONFIG_TREE_RCU, or CONFIG_PREEMPT_RCU?

    And one other thing... CONFIG_CLASSIC_RCU's synchronize_rcu() normally
    runs faster than CONFIG_PREEMPT_RCU, if that helps.

    Thanx, Paul


    \
     
     \ /
      Last update: 2009-03-20 23:23    [W:0.023 / U:30.508 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site