Re: [PATCH 05/32] nohz: Move rcu dynticks idle mode handling to idleenter/exit APIs

[Frederic Weisbecker]

On Tue, Aug 30, 2011 at 05:42:32PM +0200, Peter Zijlstra wrote:
> On Tue, 2011-08-30 at 17:33 +0200, Frederic Weisbecker wrote:
> > > See all that is still kernelspace ;-) I think I know what you mean to
> > > say though, but seeing as you note there is even now a known shortcoming
> > > I'm not very confident its a solid construction. What will help us find
> > > such holes?
> > 
> > This: https://lkml.org/lkml/2011/6/23/744
> > 
> > It's in one of Paul's branches and should make it for the next merge window.
> > This should detect any of such holes. I made that on purpose for the nohz cpusets
> > when I saw how much error prone that can be with rcu :)
> 
> OK, good ;-)
> 
> > > I would much rather we not rely on such fragile things too much.. this
> > > RCU stuff wants way more thought, as it stands your patch-set doesn't do
> > > anything useful IMO.
> > 
> > Not sure what you mean. Well that Rcu thing for sure is fragile but we have
> > the tools ready to find the problems. 
> 
> Right that thing you linked above does catch abuse, still your current
> proposal means that due to RCU it will basically never disable the tick.

At least if we are in userspace it does as long as we have no local rcu callbacks
to handle. We have the rcu_pending() check but we can remove it for userspace.

Now for the kernel space I still think it's worth, for example when all other
CPUs are idle, or when they don't queue that much RCU callbacks. In theory if
we have a grace period to complete 100 times per second but HZ=1000 then we
are going to avoid a lot of timer interrupts.
If we can't remove the timer, we can at least minimize it.
--
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/