linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Dave Airlie <airlied@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	Kees Cook <keescook@chromium.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Serge Hallyn <serge.hallyn@canonical.com>,
	"David S. Miller" <davem@davemloft.net>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default
Date: Sun, 7 Oct 2012 09:30:29 -0700	[thread overview]
Message-ID: <20121007163029.GG2485@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAPM=9tzoaZ3AWzA6MFnKAMzFgrarWW=JTLHSTzGBf0hoPQ_RmQ@mail.gmail.com>

On Sun, Oct 07, 2012 at 12:33:48PM +1000, Dave Airlie wrote:
> >>
> >> Really I would much prefer to add some "Don't enable it unless you're
> >> doing kernel hacking.
> >> If unsure say N" text in the Kconfig.
> >>
> >> I can understand that distros want to cover as much feature as they
> >> can for their users. But
> >> should it be an excuse for not reading outstanding warnings in Kconfig
> >> help text?
> >
> > In my experience, they do not read these warnings carefully.  :-(
> > Or perhaps they do read them, but react to them by running the code
> > through some test suite rather than by putting full faith in the
> > warning.
> 
> I think Kconfig is mostly what distro would like to use the thing is
> the Kconfig text needs to be there upfront when its merged, not two
> months later, since then it too late for a distro to notice.
> 
> I'd bet most distros would read the warnings, but in a lot of cases
> the warning don't exist until its too late.

In the case of CONFIG_RCU_USER_QS you are quite right, the warning
should have been there from the beginning and was not.  I suppose you
could argue that the warning was not sufficiently harsh in the case of
CONFIG_RCU_FAST_NO_HZ, but either way it did get ignored:

config RCU_FAST_NO_HZ
	bool "Accelerate last non-dyntick-idle CPU's grace periods"
	depends on TREE_RCU && NO_HZ && SMP
	default n
	help
	  This option causes RCU to attempt to accelerate grace periods
	  in order to allow the final CPU to enter dynticks-idle state
	  more quickly.  On the other hand, this option increases the
	  overhead of the dynticks-idle checking, particularly on systems
	  with large numbers of CPUs.

	  Say Y if energy efficiency is critically important, particularly
	  	if you have relatively few CPUs.

	  Say N if you are unsure.

I have since made RCU_FAST_NO_HZ more generally applicable, so it is
OK to enable now.  I suppose I need to update the help text...

Either way, however, it would be good to tag an experimental config
option at boot time.  Even if the help text gives very clear warnings,
it would be good to have the option defend itself against the occasional
inevitable typo.

							Thanx, Paul

> Dave.
> 
> 
> >> Or may be add some specific warning yeah. I wouldn't mind much.
> >
> > We have some weeks to think about it -- I cannot see pushing a
> > warning in as a regression.  ;-)
> >
> >                                                         Thanx, Paul
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 


  reply	other threads:[~2012-10-07 16:30 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-02 19:50 [PATCH] make CONFIG_EXPERIMENTAL invisible and default Kees Cook
2012-10-02 21:40 ` Serge E. Hallyn
2012-10-03 13:25 ` Paul E. McKenney
2012-10-03 16:15   ` Kees Cook
2012-10-03 16:43     ` Josh Boyer
2012-10-03 16:16   ` Serge Hallyn
2012-10-03 16:17   ` Greg Kroah-Hartman
2012-10-03 16:47     ` Paul E. McKenney
2012-10-03 17:21       ` Greg Kroah-Hartman
2012-10-03 17:46         ` Frederic Weisbecker
2012-10-03 18:23           ` Josh Boyer
2012-10-03 19:36           ` Dave Jones
2012-10-03 20:05             ` Paul E. McKenney
2012-10-03 21:43             ` Frederic Weisbecker
2012-10-04 14:31               ` Paul E. McKenney
2012-10-03 17:46         ` Paul E. McKenney
2012-10-03 18:02           ` Serge Hallyn
2012-10-03 18:43       ` Kees Cook
2012-10-03 19:07         ` david
2012-10-03 20:03         ` Paul E. McKenney
2012-10-03 22:23           ` Eric W. Biederman
2012-10-04  0:11             ` Paul E. McKenney
2012-10-04  1:55           ` Matthew Garrett
2012-10-04 14:31             ` Paul E. McKenney
2012-10-05 16:46               ` Paul E. McKenney
2012-10-06 16:10                 ` Frederic Weisbecker
2012-10-07  1:44                   ` Paul E. McKenney
2012-10-07  2:33                     ` Dave Airlie
2012-10-07 16:30                       ` Paul E. McKenney [this message]
2012-10-07 20:18                         ` Dave Jones
2012-10-08  1:04                           ` Paul E. McKenney
2012-10-08 22:07                             ` Kees Cook
2012-10-08 22:29                               ` Paul E. McKenney
2012-10-08 22:37                                 ` Kees Cook
2012-10-08 22:40                                   ` Kees Cook
2012-10-08 22:59                                     ` Paul E. McKenney
2012-10-08 23:23                                       ` Kees Cook
2012-10-03 21:31         ` Frederic Weisbecker
2012-10-08 22:08     ` Kees Cook
2012-10-08 23:53       ` Greg Kroah-Hartman
2012-10-09  0:46         ` Kees Cook
2012-10-09  1:20           ` Greg Kroah-Hartman
2012-10-09  1:26           ` Paul E. McKenney
2012-10-09  1:57             ` Kees Cook
2012-10-09  2:47               ` Stephen Rothwell
2012-10-09  6:01                 ` Kees Cook
2012-12-16  4:29     ` Jan Engelhardt
2012-12-16 16:19       ` Paul E. McKenney
2012-10-03 23:29 ` Guenter Roeck
2012-10-03 23:33   ` Kees Cook
2012-10-03 23:37     ` Guenter Roeck

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=20121007163029.GG2485@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=fweisbec@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=serge.hallyn@canonical.com \
    /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;
as well as URLs for NNTP newsgroup(s).