Re: [PATCH RFC tip/core/rcu] Add callback-free CPUs

[Peter Zijlstra <peterz@infradead.org>]

On Wed, 2012-09-05 at 16:44 -0700, Paul E. McKenney wrote:

> I was excited by this possibility when you first mentioned it, but
> the low-OS-jitter fans are going to need the grace-period computation
> to be offloaded as well. 

Sure, but it seems to me pulling the grace period machinery out is a
much harder feat and should be a patch (series) on its own. Also..

>  So if I use your (admittedly much simpler)
> approach, I get to rewrite it when Frederic's adaptive-ticks work goes
> in. 

I don't see how Frederic's work affects any of this, that would simple
put RCU into extended quiescent state (aka. idle) while in userspace. In
that state the grace period machinery is stopped all together, so it
doesn't matter who would've ran it. 

>  Given that this is probably happening relatively soon, it would be
> better if I just did the implementation that will be needed long-term,
> rather than rewriting.
> 
> Though I am sure that people will be sad about fewer RCU patches.  ;-)

Always...

Now thinking about this grace machinery stuff a little more, would it be
possible to stick the entire state machine in a kthread and replace all
current hooks, like the tick and rcu_read_unlock_special with a message
passing construct such that they pass their event on to the kthread?

That way you could run the entire state thing from a kthread with random
affinity, all 'per-cpu' data would still be fine since only the one
kthread will access it, even though locality might suffer somewhat.

This would also not suffer from the having to keep one cpu special and
the ugly bouncing etc..