Messages in this thread | | | Subject | Re: [PATCH tip/core/rcu 11/26] rcu: Exit RCU extended QS on user preemption | From | Peter Zijlstra <> | Date | Wed, 12 Sep 2012 14:41:36 +0200 |
| |
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.
> 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?
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 ?
| |