[lkml]   [2010]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH RFC tip/core/rcu] accelerate grace period if last non-dynticked CPU
    On Wed, Jan 27, 2010 at 10:50:50AM +0100, Peter Zijlstra wrote:
    > On Wed, 2010-01-27 at 10:43 +0100, Andi Kleen wrote:
    > >
    > > Can't you simply check that at runtime then?
    > >
    > > if (num_possible_cpus() > 20)
    > > ...
    > >
    > > BTW the new small is large. This years high end desktop PC will come with
    > > upto 12 CPU threads. It would likely be challenging to find a good
    > > number for 20 that holds up with the future.
    > If only scalability were that easy :/
    > These massive core/thread count things are causing more problems as
    > well, the cpus/node ratios are constantly growing, giving grief in the
    > page allocator as well as other places that used to scale per node.
    > As to the current problem, the call_rcu() interface doesn't make a hard
    > promise that the callback will be done on the same cpu, right? So why
    > not simply move the callback list over to a more active cpu?

    I could indeed do that. However, there is nothing stopping the
    more-active CPU from going into dynticks-idle mode between the time
    that I decide to push the callback to it and the time I actually do
    the pushing. :-(

    I considered pushing the callbacks to the orphanage, but that is a
    global lock that I would rather not acquire on each dyntick-idle

    This conversation is having the effect of making me much more comfortable
    adding a kernel configuration parameter. Might not have been the intent,
    but there you have it! ;-)

    Thanx, Paul

     \ /
      Last update: 2010-01-27 11:07    [W:0.022 / U:2.392 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site