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 for Android: free password hash cracker in your pocket

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

Message-ID: <20120523135717.GC1663@somewhere>
Date:	Wed, 23 May 2012 15:57:24 +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 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().

> 
> > Signed-off-by: Frederic Weisbecker <fweisbec@...il.com>
> > Cc: Alessio Igor Bogani <abogani@...nel.org>
> > Cc: Andrew Morton <akpm@...ux-foundation.org>
> > Cc: Avi Kivity <avi@...hat.com>
> > Cc: Chris Metcalf <cmetcalf@...era.com>
> > Cc: Christoph Lameter <cl@...ux.com>
> > Cc: Daniel Lezcano <daniel.lezcano@...aro.org>
> > Cc: Geoff Levand <geoff@...radead.org>
> > Cc: Gilad Ben Yossef <gilad@...yossef.com>
> > Cc: Hakan Akkan <hakanakkan@...il.com>
> > Cc: Ingo Molnar <mingo@...nel.org>
> > Cc: Kevin Hilman <khilman@...com>
> > Cc: Max Krasnyansky <maxk@...lcomm.com>
> > Cc: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > Cc: Peter Zijlstra <peterz@...radead.org>
> > Cc: Stephen Hemminger <shemminger@...tta.com>
> > Cc: Steven Rostedt <rostedt@...dmis.org>
> > Cc: Sven-Thorsten Dietrich <thebigcorporation@...il.com>
> > Cc: Thomas Gleixner <tglx@...utronix.de>
> > ---
> >  kernel/rcutree.c |   17 +++++++++++++++++
> >  1 files changed, 17 insertions(+), 0 deletions(-)
> > 
> > diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> > index e141c7e..3fffc26 100644
> > --- a/kernel/rcutree.c
> > +++ b/kernel/rcutree.c
> > @@ -50,6 +50,7 @@
> >  #include <linux/wait.h>
> >  #include <linux/kthread.h>
> >  #include <linux/prefetch.h>
> > +#include <linux/cpuset.h>
> > 
> >  #include "rcutree.h"
> >  #include <trace/events/rcu.h>
> > @@ -302,6 +303,20 @@ static struct rcu_node *rcu_get_root(struct rcu_state *rsp)
> > 
> >  #ifdef CONFIG_SMP
> > 
> > +static void cpuset_update_rcu_cpu(int cpu)
> > +{
> > +#ifdef CONFIG_CPUSETS_NO_HZ
> > +	unsigned long flags;
> > +
> > +	local_irq_save(flags);
> > +
> > +	if (cpuset_cpu_adaptive_nohz(cpu))
> > +		smp_cpuset_update_nohz(cpu);
> > +
> > +	local_irq_restore(flags);
> > +#endif
> > +}
> > +
> >  /*
> >   * If the specified CPU is offline, tell the caller that it is in
> >   * a quiescent state.  Otherwise, whack it with a reschedule IPI.
> > @@ -325,6 +340,8 @@ static int rcu_implicit_offline_qs(struct rcu_data *rdp)
> >  		return 1;
> >  	}
> > 
> > +	cpuset_update_rcu_cpu(rdp->cpu);
> > +
> >  	/*
> >  	 * The CPU is online, so send it a reschedule IPI.  This forces
> >  	 * it through the scheduler, and (inefficiently) also handles cases
> > -- 
> > 1.7.5.4
> > 
> 
--
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/