linux-kernel - Re: [PATCH RFC tip/core/rcu 19/28] nohz: Allow rcu extended quiescent state handling seperately from tick stop

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: <20111103160656.GC2287@linux.vnet.ibm.com>
Date:	Thu, 3 Nov 2011 09:06:56 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...ymtl.ca, niv@...ibm.com, tglx@...utronix.de,
	peterz@...radead.org, rostedt@...dmis.org, Valdis.Kletnieks@...edu,
	dhowells@...hat.com, eric.dumazet@...il.com, darren@...art.com,
	patches@...aro.org, Mike Frysinger <vapier@...too.org>,
	Guan Xuetao <gxt@...c.pku.edu.cn>,
	David Miller <davem@...emloft.net>,
	Chris Metcalf <cmetcalf@...era.com>,
	Hans-Christian Egtvedt <hans-christian.egtvedt@...el.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"H. Peter Anvin" <hpa@...or.com>,
	Russell King <linux@....linux.org.uk>,
	Paul Mackerras <paulus@...ba.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH RFC tip/core/rcu 19/28] nohz: Allow rcu extended
 quiescent state handling seperately from tick stop

On Thu, Nov 03, 2011 at 08:31:02AM -0700, Josh Triplett wrote:
> On Thu, Nov 03, 2011 at 06:32:31AM -0700, Paul E. McKenney wrote:
> > On Thu, Nov 03, 2011 at 12:54:33PM +0100, Frederic Weisbecker wrote:
> > > On Wed, Nov 02, 2011 at 09:00:03PM -0700, Josh Triplett wrote:
> > > > On Wed, Nov 02, 2011 at 01:30:40PM -0700, Paul E. McKenney wrote:
> > > > > From: Frederic Weisbecker <fweisbec@...il.com>
> > > > > 
> > > > > It is assumed that rcu won't be used once we switch to tickless
> > > > > mode and until we restart the tick. However this is not always
> > > > > true, as in x86-64 where we dereference the idle notifiers after
> > > > > the tick is stopped.
> > > > > 
> > > > > To prepare for fixing this, add two new APIs:
> > > > > tick_nohz_idle_enter_norcu() and tick_nohz_idle_exit_norcu().
> > > > > 
> > > > > If no use of RCU is made in the idle loop between
> > > > > tick_nohz_enter_idle() and tick_nohz_exit_idle() calls, the arch
> > > > > must instead call the new *_norcu() version such that the arch doesn't
> > > > > need to call rcu_idle_enter() and rcu_idle_exit().
> > > > 
> > > > The _norcu names confused me a bit.  At first, I thought they meant
> > > > "idle but not RCU idle, so you can use RCU", but from re-reading the
> > > > commit message, apparently they mean "idle and RCU idle, so don't use
> > > > RCU".  What about something like _forbid_rcu instead?  Or,
> > > > alternatively, why not just go ahead and separate the two types of idle
> > > > entirely rather than introducing the _norcu variants first?
> > > 
> > > Or tick_nohz_idle_enter_rcu_stop() and tick_nohz_idle_exit_rcu_restart()?
> > > 
> > > Sounds clear but too long. May be we can shorten the tick_nohz thing in the
> > > beginning.
> > 
> > How about tick_nohz_rcu_idle_enter() vs. tick_nohz_idle_enter() on
> > entry to the idle loop and tick_nohz_rcu_idle_exit() vs
> > tick_nohz_idle_exit() on exit?
> > 
> > That said, I don't feel all that strongly on this naming topic.
> 
> Mostly I think that since this series tries to separate the concepts of
> "idle nohz" and "rcu extended quiescent state", we should end up with
> two entirely separate functions delimiting those two, without any
> functions that poke both with correspondingly complex compound names.

Having four API members rather than the current six does seem quite
attractive to me.  Frederic, any reason why this approach won't work?

						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/