linux-kernel - Re: [PATCH 16/41] rcu: Restart the tick on non-responding adaptive nohz CPUs

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: <20120523155738.GI1663@somewhere>
Date:	Wed, 23 May 2012 17:57:48 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	linaro-sched-sig@...ts.linaro.org,
	Alessio Igor Bogani <abogani@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Avi Kivity <avi@...hat.com>,
	Chris Metcalf <cmetcalf@...era.com>,
	Christoph Lameter <cl@...ux.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Geoff Levand <geoff@...radead.org>,
	Gilad Ben Yossef <gilad@...yossef.com>,
	Hakan Akkan <hakanakkan@...il.com>,
	Ingo Molnar <mingo@...nel.org>, Kevin Hilman <khilman@...com>,
	Max Krasnyansky <maxk@...lcomm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Stephen Hemminger <shemminger@...tta.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Sven-Thorsten Dietrich <thebigcorporation@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 16/41] rcu: Restart the tick on non-responding adaptive
 nohz CPUs

On Wed, May 23, 2012 at 08:20:09AM -0700, Paul E. McKenney wrote:
> On Wed, May 23, 2012 at 03:57:24PM +0200, Frederic Weisbecker wrote:
> > On Tue, May 22, 2012 at 10:20:50AM -0700, Paul E. McKenney wrote:
> > > On Tue, May 01, 2012 at 01:54:50AM +0200, Frederic Weisbecker wrote:
> > > > When a CPU in adaptive nohz mode doesn't respond to complete
> > > > a grace period, issue it a specific IPI so that it restarts
> > > > the tick and chases a quiescent state.
> > > 
> > > Hello, Frederic,
> > > 
> > > I don't understand the need for this patch.  If the CPU is in
> > > adaptive-tick mode, RCU should see it as being in dyntick-idle mode,
> > > right?  If so, shouldn't RCU have already recognized the CPU as being
> > > in an extended quiescent state?
> > > 
> > > Or is this a belt-and-suspenders situation?
> > > 
> > > 							Thanx, Paul
> > 
> > If the tickless CPU is in userspace, it is in extended quiescent state. But
> > not if it runs tickless in the kernel. In this case we need to send it an IPI
> > so that it restarts the tick after checking rcu_pending().
> 
> But if it has registered itself with RCU as idle, for example, by calling
> rcu_user_enter(), then RCU will be ignoring that CPU, posting quiescent
> states as needed on its behalf.  So I still don't understand the need
> for this patch.

Indeed if we are going to stop the tick and enter extended quiescent state,
we can ignore this check. I can optimize that.

But if we try to stop the tick in the kernel, which means we can still meet
RCU read side critical sections, we need to prevent from stopping the tick
if there is a global grace period to complete.
--
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/