Re: [PATCH tip/core/rcu 6/7] rcu: Drive quiescent-state-forcing delay from HZ

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Tue, May 14, 2013 at 04:51:20PM +0200, Peter Zijlstra wrote:
> > In theory, yes.  In practice, this requires lots of lock acquisitions
> > and releases on large systems, including some global locks.  The weight
> > could be reduced, but...
> > 
> > What I would like to do instead would be to specify expedited grace
> > periods during boot.
> 
> But why, surely going idle without any RCU callbacks isn't completely unheard
> of, even outside of the boot process?

Yep, and RCU has special-cased that for quite some time.

> Being able to quickly drop out of the RCU state machinery would be a good thing IMO.

And this is currently possible -- this is the job of rcu_idle_enter()
and friends.  And it works well, at least when I get my "if" statements
set up correctly (hence the earlier patch).

Or are you seeing a slowdown even with that earlier patch applied?  If so,
please let me know what you are seeing.

> >  The challenge here appears to be somehow telling
> > RCU when boot is done.  The APIs are there from an RCU viewpoint:  boot
> > with rcupdate.rcu_expedited=1, then, once boot is complete (whatever
> > that means on your platform) "echo 0 > /sys/kernel/rcu_expedited".
> 
> Ha, and here you assume userspace is sane and co-operative. Fail in my book ;-)

If they are insane or uncooperative, they pay the price.  ;-)

							Thanx, Paul