Date:	Sat, 18 Apr 2015 06:34:44 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	a.p.zijlstra@...llo.nl, akpm@...ux-foundation.org
Subject: Re: [GIT RFC PULL rcu/urgent] Prevent Kconfig from asking pointless
 questions

On Sat, Apr 18, 2015 at 03:03:41PM +0200, Ingo Molnar wrote:
> 
> * Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:
> 
> > Hello, Ingo,
> > 
> > This series contains a single change that fixes Kconfig asking pointless
> > questions (https://lkml.org/lkml/2015/4/14/616).  This is an RFC pull
> > because there has not yet been a -next build for April 16th.  If you
> > would prefer to wait until after -next has pulled this, please let me
> > know and I will redo this pull request after that has happened.
> > 
> > In the meantime, this change is available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git for-mingo
> > 
> > for you to fetch changes up to 8d7dc9283f399e1fda4e48a1c453f689326d9396:
> > 
> >   rcu: Control grace-period delays directly from value (2015-04-14 19:33:59 -0700)
> > 
> > ----------------------------------------------------------------
> > Paul E. McKenney (1):
> >       rcu: Control grace-period delays directly from value
> > 
> >  kernel/rcu/tree.c | 16 +++++++++-------
> >  lib/Kconfig.debug |  1 +
> >  2 files changed, 10 insertions(+), 7 deletions(-)
> 
> Pulled, thanks a lot Paul!
> 
> Note, while this fixes Linus's immediate complaint that arose from the 
> new option, I still think we need to do more fixes in this area.

Good point!

> To demonstrate the current situation I tried the following experiment, 
> I did a 'make defconfig' on an x86 box and then took the .config and 
> deleted all 'RCU Subsystem' options not marked as debugging.
> 
> Then I did a 'make oldconfig' to see what kinds of questions a user is 
> facing when trying to configure RCU:
> 
> 	*
> 	* Restart config...
> 	*
> 	*
> 	* RCU Subsystem
> 	*
> 	RCU Implementation
> 	> 1. Tree-based hierarchical RCU (TREE_RCU) (NEW)
> 	choice[1]: 1

Hmmm...  Given that there is no choice, I agree that it is a bit silly
to ask...

> 	Task_based RCU implementation using voluntary context switch (TASKS_RCU) [N/y/?] (NEW) 

Agreed, this one should be driven directly off of CONFIG_RCU_TORTURE_TEST
and the tracing use case.

> 	Consider userspace as in RCU extended quiescent state (RCU_USER_QS) [N/y/?] (NEW) 

This should be driven directly off of CONFIG_NO_HZ_FULL, unless
Frederic knows something I don't.

> 	Tree-based hierarchical RCU fanout value (RCU_FANOUT) [64] (NEW) 

Hmmm...  I could drop/obscure this one in favor of a boot parameter.

> 	Tree-based hierarchical RCU leaf-level fanout value (RCU_FANOUT_LEAF) [16] (NEW) 

Ditto -- though large configurations really do set this to 64 in combination
with the skew_tick boot parameter.  Maybe we need to drive these off of
some large-system parameter, like CONFIG_MAX_SMP.

> 	Disable tree-based hierarchical RCU auto-balancing (RCU_FANOUT_EXACT) [N/y/?] (NEW) 

I should just make this a boot parameter.  Absolutely no reason for it to
be a Kconfig parameter.

> 	Accelerate last non-dyntick-idle CPU's grace periods (RCU_FAST_NO_HZ) [N/y/?] (NEW) 

On this one, I have no idea.  Its purpose is energy efficiency, but it
does have some downsides, for example, increasing idle entry/exit latency.
I am a bit nervous about having it be a boot parameter because that
would leave an extra compare-branch in the path.  This one will require
some thought.

> 	Real-time priority to use for RCU worker threads (RCU_KTHREAD_PRIO) [0] (NEW) 

Indeed, Linus complained about this one.  ;-)

This Kconfig parameter is a stopgap, and needs a real solution.  People
with crazy-heavy workloads involving realtime cannot live without it,
but that means that most people don't have to care.  I have had solving
this on my list, and this clearly increases its priority.

> 	Offload RCU callback processing from boot-selected CPUs (RCU_NOCB_CPU) [N/y/?] (NEW) 

Hmmm...  Maybe a boot parameter, but I thought that there was some reason
that this was problematic.  I will have to take another look.

Anyway, this one is important to non-NO_HZ_FULL real-time workloads.
In a -rt kernel, making CONFIG_PREEMPT_RT (or whatever it is these
days) drive this one makes a lot of sense.

> 	#
> 	# configuration written to .config
> 	#
> 
> Only TREE_RCU is available on defconfig, so all the other options 
> marked with '(NEW)' were offered as an interactive prompt.
> 
> I don't think that any of the 8 interactive options (!) here are 
> particularly useful to even advanced users who configure kernels, and 
> I don't think they should be offered under non-expert settings.

Would it make sense to have a CONFIG_RCU_EXPERT setting to hide the
remaining settings?  That would reduce the common-case number of
questions to one, which would be a quick and safe improvement.
Especially when combined with the changes I called out above.

> Instead we should pick a preferred RCU configuration based on other 
> hints (such as CONFIG_NR_CPUS and CONFIG_NO_HZ settings), and if users 
> or distribution makers find some problem with that, we should address 
> those specific complaints.
> 
> Making everything under the sun configurable, with which non-RCU 
> experts cannot really do anything anyway, isn't very user friendly - 
> and results in:
> 
>  - user confusion and frustration
> 
>  - possibly messed up configurations
> 
>  - it also hides inefficiencies that might arise from our defaults: 
>    someone genuinely finding a problem might just tweak the .config, 
>    without ever communicating that bad default to us.
> 
> So doing (much!) less is in general the best option for Kconfig driven 
> UIs.

I certainly cannot argue with this point!

							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/

Powered by blists - more mailing lists