• Paul E. McKenney's avatar
    rcu: Make RCU_FAST_NO_HZ handle timer migration · 21e52e15
    Paul E. McKenney authored
    The current RCU_FAST_NO_HZ assumes that timers do not migrate unless a
    CPU goes offline, in which case it assumes that the CPU will have to come
    out of dyntick-idle mode (cancelling the timer) in order to go offline.
    This is important because when RCU_FAST_NO_HZ permits a CPU to enter
    dyntick-idle mode despite having RCU callbacks pending, it posts a timer
    on that CPU to force a wakeup on that CPU.  This wakeup ensures that the
    CPU will eventually handle the end of the grace period, including invoking
    its RCU callbacks.
    
    However, Pascal Chapperon's test setup shows that the timer handler
    rcu_idle_gp_timer_func() really does get invoked in some cases.  This is
    problematic because this can cause the CPU that entered dyntick-idle
    mode despite still having RCU callbacks pending to remain in
    dyntick-idle mode indefinitely, which means that its RCU callbacks might
    never be invoked.  This situation can result in grace-period delays or
    even system hangs, which matches Pascal's observations of slow boot-up
    and shutdown (https://lkml.org/lkml/2012/4/5/142).  See also the bugzilla:
    
    	https://bugzilla.redhat.com/show_bug.cgi?id=806548
    
    This commit therefore causes the "should never be invoked" timer handler
    rcu_idle_gp_timer_func() to use smp_call_function_single() to wake up
    the CPU for which the timer was intended, allowing that CPU to invoke
    its RCU callbacks in a timely manner.
    Reported-by: default avatarPascal Chapperon <pascal.chapperon@wanadoo.fr>
    Signed-off-by: default avatarPaul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
    21e52e15
rcu.h 16 KB