Messages in this thread | | | Date | Thu, 31 May 2012 17:56:30 +0200 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 17/41] rcu: Restart tick if we enqueue a callback in a nohz/cpuset CPU |
| |
On Wed, May 23, 2012 at 09:15:14AM -0700, Paul E. McKenney wrote: > On Wed, May 23, 2012 at 04:03:36PM +0200, Frederic Weisbecker wrote: > > On Tue, May 22, 2012 at 10:30:47AM -0700, Paul E. McKenney wrote: > > > On Tue, May 22, 2012 at 10:27:14AM -0700, Paul E. McKenney wrote: > > > > On Tue, May 01, 2012 at 01:54:51AM +0200, Frederic Weisbecker wrote: > > > > > If we enqueue an rcu callback, we need the CPU tick to stay > > > > > alive until we take care of those by completing the appropriate > > > > > grace period. > > > > > > > > > > Thus, when we call_rcu(), send a self IPI that checks rcu_needs_cpu() > > > > > so that we restore a periodic tick behaviour that can take care of > > > > > everything. > > > > > > > > Ouch, I hadn't considered RCU callbacks being posted from within an > > > > extended quiescent state. I guess I need to make __call_rcu() either > > > > complain about this or handle it correctly... It would -usually- be > > > > harmless, but there is getting to be quite a bit of active machinery > > > > in the various idle loops, so just assuming that it cannot happen is > > > > probably getting to be an obsolete assumption. > > > > > > Adaptive ticks does restart the tick upon entering the kernel, correct? > > > > No, it keeps the tick down. The tick is restarted only if it's needed: > > when more than one task are on the runqueue, a posix cpu timer is running, > > a CPU needs the current one to report a quiescent state, etc... > > Ah, I didn't realize that you didn't restart the tick upon entry to the > kernel. So this is why you need the IPI -- because there is no tick, if > the system call runs for a long time, RCU is not guaranteed to make any > progress on that CPU. > > In the common case, this will not be a problem because system calls > normally spend a short amount of time in the kernel, so normally RCU's > dyntick-idle detection will handle this case. The exception to this > rule is when there is a long CPU-bound code path in the kernel, where > "long" means many milliseconds. In this exception case, this CPU needs > to be interrupted or whatever is needed to force the CPU to progress > through RCU.
Exactly!
| |