linux-kernel - Re: [PATCH 11/41] nohz/cpuset: Don't turn off the tick if rcu needs it

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: <20120523162739.GE2402@linux.vnet.ibm.com>
Date:	Wed, 23 May 2012 09:27:39 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Frederic Weisbecker <fweisbec@...il.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 11/41] nohz/cpuset: Don't turn off the tick if rcu needs
 it

On Wed, May 23, 2012 at 06:06:33PM +0200, Frederic Weisbecker wrote:
> On Wed, May 23, 2012 at 08:15:42AM -0700, Paul E. McKenney wrote:
> > On Wed, May 23, 2012 at 03:52:09PM +0200, Frederic Weisbecker wrote:
> > > > > +#ifdef CONFIG_CPUSETS_NO_HZ
> > > > > +static bool can_stop_adaptive_tick(void)
> > > > > +{
> > > > > +	if (!sched_can_stop_tick())
> > > > > +		return false;
> > > > > +
> > > > > +	/* Is there a grace period to complete ? */
> > > > > +	if (rcu_pending(smp_processor_id()))
> > > > 
> > > > You lost me on this one.  Why can't this be rcu_needs_cpu()?
> > > 
> > > We already have an rcu_needs_cpu() check in tick_nohz_stop_sched_tick()
> > > that prevents the tick to shut down if the CPU has local callbacks to handle.
> > > 
> > > The rcu_pending() check is there in case some other CPU is waiting for the
> > > current one to help completing a grace period, by reporting a quiescent state
> > > for example. This happens because we may stop the tick in the kernel, not only
> > > userspace. And if we are in the kernel, we still need to be part of the global
> > > state machine.
> > 
> > Ah!  But RCU will notice that the CPU is in dyntick-idle mode, and will
> > therefore take any needed quiescent-state action on that CPU's behalf.
> > So there should be no need to call rcu_pending() anywhere outside of the
> > RCU core code.
> 
> No. If the tick is stopped and we are in the kernel, we may be using RCU
> anytime, so we need to be part of the RCU core.

OK, so the only problem is if we spend a long time CPU-bound in the kernel,
where "long" is milliseconds or tens of milliseconds.  In that case, the
RCU core will notice that the CPU has not responded but is not idle, for
example, in rcu_implicit_dynticks_qs().  It can take action at this point
to get the offending CPU to pay attention to RCU.

Does this make sense, or am I still missing something?

--
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/