Re: [PATCH tip/core/rcu 11/26] rcu: Exit RCU extended QS on userpreemption

[Peter Zijlstra]

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 ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/