linux-kernel - Re: [PATCH tip/core/rcu 6/9] nohz_full: Add full-system idle states and variables

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]

Date:	Sun, 18 Aug 2013 19:49:14 -0700
From:	Josh Triplett <josh@...htriplett.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	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, dhowells@...hat.com,
	edumazet@...gle.com, darren@...art.com, fweisbec@...il.com,
	sbw@....edu
Subject: Re: [PATCH tip/core/rcu 6/9] nohz_full: Add full-system idle states
 and variables

On Sun, Aug 18, 2013 at 06:39:25PM -0700, Paul E. McKenney wrote:
> On Sat, Aug 17, 2013 at 08:09:21PM -0700, Josh Triplett wrote:
> > On Sat, Aug 17, 2013 at 06:49:41PM -0700, Paul E. McKenney wrote:
> > > From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
> > > 
> > > This commit adds control variables and states for full-system idle.
> > > The system will progress through the states in numerical order when
> > > the system is fully idle (other than the timekeeping CPU), and reset
> > > down to the initial state if any non-timekeeping CPU goes non-idle.
> > > The current state is kept in full_sysidle_state.
> > > 
> > > A RCU_SYSIDLE_SMALL macro is defined, and systems with this number
> > > of CPUs or fewer move through the states more aggressively.  The idea
> > > is that the resulting memory contention is less of a problem on small
> > > systems.  Architectures can adjust this value (which defaults to 8)
> > > using CONFIG_ARCH_RCU_SYSIDLE_SMALL.
> > > 
> > > One flavor of RCU will be in charge of driving the state machine,
> > > defined by rcu_sysidle_state.  This should be the busiest flavor of RCU.
> > > 
> > > Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > > Cc: Frederic Weisbecker <fweisbec@...il.com>
> > > Cc: Steven Rostedt <rostedt@...dmis.org>
> > 
> > One issue (and one question) below; with the issue addressed,
> > Reviewed-by: Josh Triplett <josh@...htriplett.org>
> > 
> > >  kernel/rcutree_plugin.h | 28 ++++++++++++++++++++++++++++
> > >  1 file changed, 28 insertions(+)
> > > 
> > > diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> > > index eab81da..64a05b9f 100644
> > > --- a/kernel/rcutree_plugin.h
> > > +++ b/kernel/rcutree_plugin.h
> > > @@ -2378,6 +2378,34 @@ static void rcu_kick_nohz_cpu(int cpu)
> > >  #ifdef CONFIG_NO_HZ_FULL_SYSIDLE
> > >  
> > >  /*
> > > + * Handle small systems specially, accelerating their transition into
> > > + * full idle state.  Allow arches to override this code's idea of
> > > + * what constitutes a "small" system.
> > > + */
> > > +#ifdef CONFIG_ARCH_RCU_SYSIDLE_SMALL
> > 
> > I don't see any Kconfig creating this new config option.
> > 
> > Also, why not simply define this config option unconditionally, with a
> > default of 8, and then use its value directly?
> 
> Good point, removing this and adding a Kconfig option in the
> "nohz_full: Add full-system-idle state machine" commit, with a
> default value of 8.  Architecture maintainers who want something
> different can then set that up in their defconfig files.

Sounds good.

> > > +static int __maybe_unused full_sysidle_state; /* Current system-idle state. */
> > > +#define RCU_SYSIDLE_NOT		0	/* Some CPU is not idle. */
> > > +#define RCU_SYSIDLE_SHORT	1	/* All CPUs idle for brief period. */
> > > +#define RCU_SYSIDLE_LONG	2	/* All CPUs idle for long enough. */
> > > +#define RCU_SYSIDLE_FULL	3	/* All CPUs idle, ready for sysidle. */
> > > +#define RCU_SYSIDLE_FULL_NOTED	4	/* Actually entered sysidle state. */
> > 
> > Perhaps there's a kernel style rule I'm not thinking of that makes it
> > verboten, but: why not use an enum for a state variable like this?
> 
> I didn't trust enum interactions with xchg and cmpxchg, so opted for "int"
> instead.  That said, enum is much more portable than when I last looked
> at it.  Admittedly, the last time I looked at it was in the early 1980s...

That would make sense if this was an atomic_t, but it's an int; unless I
missed something, you don't currently use xchg or cmpxchg on it.

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