| Date | Thu, 2 Feb 2012 10:27:05 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH RFC tip/core/rcu 39/41] rcu: Wait at least a jiffy before declaring a CPU to be offline |
| |
On Wed, Feb 01, 2012 at 10:12:28PM -0800, Josh Triplett wrote: > On Wed, Feb 01, 2012 at 11:41:57AM -0800, Paul E. McKenney wrote: > > From: "Paul E. McKenney" <paul.mckenney@linaro.org> > > > > The force_quiescent_state() function uses a state machine to help > > force grace periods to completion. One of its responsibilities is to > > detect offline CPUs, and to report quiescent states on their behalf. > > However, the CPU hotplug process is not atomic, in fact, there is > > significant uncertainty as to exactly when a given CPU came online or > > went offline. For example, once a CPU has marked itself offline and > > executed the CPU_DYING notifiers, it continues executing, entering > > the scheduler and perhaps also the idle loop. > > > > In the old days, force_quiescent_state() was guaranteed to wait for > > several jiffies before declaring a given CPU offline. This is no > > longer the case, due to some of the more aggressive rcutorture tests > > and the CONFIG_RCU_FAST_NO_HZ idle-entry code. Therefore, this commit > > makes force_quiescent_state() explicitly wait for at least a jiffy > > before declaring a CPU to be offline. > > This commit seems to implement behavior documented as working in patch > 38. Shouldn't those bits go together?
It really needs to have gone with the addition of of the fqs_ module parameters to rcutorture.c, but that was some years back. Failing that, it needs to have gone with the addition of RCU_FAST_NO_HZ, but that was more than a year ago as well.
But yes, merging with #38 makes sense to me!
The still-ongoing top-to-bottom review of RCU is still yielding results, and this is one of them. Working through the hotplug code has been time consuming, buteducational. ;-)
Thanx, Paul
|