From: Ingo Molnar <mingo@kernel.org>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
a.p.zijlstra@chello.nl, akpm@linux-foundation.org
Subject: Re: [GIT RFC PULL rcu/urgent] Prevent Kconfig from asking pointless questions
Date: Sat, 18 Apr 2015 15:03:41 +0200 [thread overview]
Message-ID: <20150418130340.GA26931@gmail.com> (raw)
In-Reply-To: <20150416183812.GA5571@linux.vnet.ibm.com>
* Paul E. McKenney <paulmck@linux.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.
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
Task_based RCU implementation using voluntary context switch (TASKS_RCU) [N/y/?] (NEW)
Consider userspace as in RCU extended quiescent state (RCU_USER_QS) [N/y/?] (NEW)
Tree-based hierarchical RCU fanout value (RCU_FANOUT) [64] (NEW)
Tree-based hierarchical RCU leaf-level fanout value (RCU_FANOUT_LEAF) [16] (NEW)
Disable tree-based hierarchical RCU auto-balancing (RCU_FANOUT_EXACT) [N/y/?] (NEW)
Accelerate last non-dyntick-idle CPU's grace periods (RCU_FAST_NO_HZ) [N/y/?] (NEW)
Real-time priority to use for RCU worker threads (RCU_KTHREAD_PRIO) [0] (NEW)
Offload RCU callback processing from boot-selected CPUs (RCU_NOCB_CPU) [N/y/?] (NEW)
#
# 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.
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.
Ingo
next prev parent reply other threads:[~2015-04-18 13:03 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-16 18:38 [GIT RFC PULL rcu/urgent] Prevent Kconfig from asking pointless questions Paul E. McKenney
2015-04-18 13:03 ` Ingo Molnar [this message]
2015-04-18 13:34 ` Paul E. McKenney
2015-04-18 14:32 ` Ingo Molnar
2015-04-19 2:05 ` Paul E. McKenney
2015-04-20 16:35 ` Clark Williams
2015-04-20 17:09 ` Paul E. McKenney
2015-04-20 17:59 ` Clark Williams
2015-04-20 18:20 ` Daniel Bristot de Oliveira
2015-04-20 18:01 ` Steven Rostedt
2015-04-20 18:09 ` Ingo Molnar
2015-04-20 18:21 ` Steven Rostedt
2015-04-20 18:28 ` Ingo Molnar
2015-04-20 18:34 ` Steven Rostedt
2015-04-21 6:42 ` Ingo Molnar
2015-04-21 13:18 ` Steven Rostedt
2015-04-21 3:37 ` Mike Galbraith
2015-04-20 20:40 ` Steven Rostedt
2015-04-20 21:15 ` Paul E. McKenney
2015-04-20 21:50 ` Clark Williams
2015-04-21 1:22 ` Paul E. McKenney
2015-04-21 13:12 ` Steven Rostedt
2015-04-21 15:01 ` Paul E. McKenney
2015-04-21 15:50 ` Steven Rostedt
2015-04-21 15:54 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150418130340.GA26931@gmail.com \
--to=mingo@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox