• Paul E. McKenney's avatar
    rcu: Simplify quiescent-state accounting · e4cc1f22
    Paul E. McKenney authored
    There is often a delay between the time that a CPU passes through a
    quiescent state and the time that this quiescent state is reported to the
    RCU core.  It is quite possible that the grace period ended before the
    quiescent state could be reported, for example, some other CPU might have
    deduced that this CPU passed through dyntick-idle mode.  It is critically
    important that quiescent state be counted only against the grace period
    that was in effect at the time that the quiescent state was detected.
    
    Previously, this was handled by recording the number of the last grace
    period to complete when passing through a quiescent state.  The RCU
    core then checks this number against the current value, and rejects
    the quiescent state if there is a mismatch.  However, one additional
    possibility must be accounted for, namely that the quiescent state was
    recorded after the prior grace period completed but before the current
    grace period started.  In this case, the RCU core must reject the
    quiescent state, but the recorded number will match.  This is handled
    when the CPU becomes aware of a new grace period -- at that point,
    it invalidates any prior quiescent state.
    
    This works, but is a bit indirect.  The new approach records the current
    grace period, and the RCU core checks to see (1) that this is still the
    current grace period and (2) that this grace period has not yet ended.
    This approach simplifies reasoning about correctness, and this commit
    changes over to this new approach.
    Signed-off-by: default avatarPaul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
    e4cc1f22
trace.txt 27 KB