Messages in this thread | | | Date | Wed, 12 Sep 2012 08:21:56 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH tip/core/rcu 11/26] rcu: Exit RCU extended QS on user preemption |
| |
On Wed, Sep 12, 2012 at 02:41:36PM +0200, Peter Zijlstra wrote: > On Wed, 2012-09-12 at 14:06 +0200, Frederic Weisbecker wrote: > > > > 1) This can happen if something calls set_need_resched() while no other task is > > on the runqueue. > > People really shouldn't be doing that... I think I know why RCU does > this, but yuck. I also think RCU can avoid doing this, but its a toss up > if that's worth the trouble.
It used to do this whenever it had to force quiescent states on a given CPU more than one time in a given grace period. I have removed this (on your advice), and the only remaining use is during RCU CPU stall warnings, where a given CPU has refused to pass through a quiescent state for more than a minute.
I could remove that one as well, if it would help. Though it would be nice to have -some- way to kick the CPU in that case. Thoughts?
> > 2) Remote wake up done but we haven't yet received the schedule IPI. > > > > 3) Non IPI remote wakeup you're referring above, I'm not sure > > what you mean though. > > Well there's two ways of doing remote wakeups, one is doing the wakeup > from the waking cpu and sending an IPI over to reschedule iff you need > wakeup-preemption, the other is queueing the task remotely and sending > an IPI to do the wakeup on the remote cpu. > > The former has the problem, the latter not. > > See ttwu_queue(). > > We could of course mandate that all remote wakeups to special nohz cpus > get queued. That would just leave us with RCU and it would simply not > send resched IPIs to extended quiescent CPUs anyway, right?
Indeed it never has done this, at least not in the absence of bugs.
Thanx, Paul
> So at that point all return to user schedule() calls have nr_running > 1 > and the tick is running and RCU is not in extended quiescent state. > Since either we had nr_running > 1 and pre and post state are the same, > or we had nr_running == 1 and we just got a fresh wakeup pushing it to > 2, the wakeup will have executed on our cpu and have re-started the tick > and kicked RCU into active gear again. > > We cannot hit return to user schedule() with nr_running == 0, simply > because in that case there's no userspace to return to, only the idle > thread and that's very much not userspace :-) > > Hmm ? > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >
| |