Re: Very high CPU load when idle with 3.0-rc1

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

On Wed, Jun 01, 2011 at 01:05:39PM +0200, Peter Zijlstra wrote:
> On Mon, 2011-05-30 at 18:45 -0700, Paul E. McKenney wrote:
> > > > Because priority boosting doesn't help unless the callbacks also run
> > > > RT priority.
> > > > 
> > > > I could make it so that they ran as normal tasks if !RCU_BOOST, but
> > > > they would still need to run as RT tasks for RCU_BOOST.  I figured
> > > > running them the same way in both cases would be simpler.
> > > 
> > > Ah, I thought you'd boost the threads along with the waiters, to the
> > > same prio so that they wouldn't disturb higher priority tasks for no
> > > reason.
> > 
> > I considered that, but working out when it is OK to deboost them is
> > decidedly non-trivial. 
> 
> Where exactly is the problem there? The boost lasts for as long as it
> takes to finish the grace period, right? There's a distinct set of
> callbacks associated with each grace-period, right? In which case you
> can de-boost your thread the moment you're done processing that set.
> 
> Or am I simply confused about how all this is supposed to work?

The main complications are: (1) the fact that it is hard to tell exactly
which grace period to wait for, this one or the next one, and (2) the
fact that callbacks get shuffled when CPUs go offline.

That said, it might be possible if we are willing to live with some
approximate behavior.  For example, always waiting for the next grace
period (rather than the current one) to finish, and boosting through the
extra callbacks in case where a given CPU "adopts" callbacks that must
be boosted when that CPU also has some callbacks whose priority must be
boosted and some that need not be.

The reason I am not all that excited about taking this approach is that
it doesn't help worst-case latency.

Plus the current implementation is just a less-precise approximation.
(Sorry, couldn't resist!)

							Thanx, Paul