[lkml]   [2013]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH tip/core/rcu 6/7] rcu: Drive quiescent-state-forcing delay from HZ
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

 \ /
  Last update: 2013-05-14 19:01    [W:0.199 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site