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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110601143743.GA2274@linux.vnet.ibm.com>
Date:	Wed, 1 Jun 2011 07:37:43 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Damien Wyart <damien.wyart@...e.fr>, Ingo Molnar <mingo@...e.hu>,
	Mike Galbraith <efault@....de>, linux-kernel@...r.kernel.org
Subject: Re: Very high CPU load when idle with 3.0-rc1

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/