lkml.org 
[lkml]   [2012]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 11/41] nohz/cpuset: Don't turn off the tick if rcu needs it
    On Wed, May 23, 2012 at 08:15:42AM -0700, Paul E. McKenney wrote:
    > On Wed, May 23, 2012 at 03:52:09PM +0200, Frederic Weisbecker wrote:
    > > > > +#ifdef CONFIG_CPUSETS_NO_HZ
    > > > > +static bool can_stop_adaptive_tick(void)
    > > > > +{
    > > > > + if (!sched_can_stop_tick())
    > > > > + return false;
    > > > > +
    > > > > + /* Is there a grace period to complete ? */
    > > > > + if (rcu_pending(smp_processor_id()))
    > > >
    > > > You lost me on this one. Why can't this be rcu_needs_cpu()?
    > >
    > > We already have an rcu_needs_cpu() check in tick_nohz_stop_sched_tick()
    > > that prevents the tick to shut down if the CPU has local callbacks to handle.
    > >
    > > The rcu_pending() check is there in case some other CPU is waiting for the
    > > current one to help completing a grace period, by reporting a quiescent state
    > > for example. This happens because we may stop the tick in the kernel, not only
    > > userspace. And if we are in the kernel, we still need to be part of the global
    > > state machine.
    >
    > Ah! But RCU will notice that the CPU is in dyntick-idle mode, and will
    > therefore take any needed quiescent-state action on that CPU's behalf.
    > So there should be no need to call rcu_pending() anywhere outside of the
    > RCU core code.


    No. If the tick is stopped and we are in the kernel, we may be using RCU
    anytime, so we need to be part of the RCU core.


    \
     
     \ /
      Last update: 2012-05-23 19:01    [W:4.037 / U:0.152 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site