All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Clark Williams <williams@redhat.com>,
	linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
	a.p.zijlstra@chello.nl, akpm@linux-foundation.org,
	linux-rt-users@vger.kernel.org
Subject: Re: [GIT RFC PULL rcu/urgent] Prevent Kconfig from asking pointless questions
Date: Mon, 20 Apr 2015 20:28:32 +0200	[thread overview]
Message-ID: <20150420182831.GA19510@gmail.com> (raw)
In-Reply-To: <20150420142149.3ac58a2c@gandalf.local.home>


* Steven Rostedt <rostedt@goodmis.org> wrote:

> On Mon, 20 Apr 2015 20:09:04 +0200
> Ingo Molnar <mingo@kernel.org> wrote:
> 
> 
> > So the disadvantage is that if a boot default is wrong, we'll hear 
> > about it eventually and can fix/improve it.
> > 
> > If a sysctl knob is wrong, people will just 'tune' it and forget 
> > to propagate it to the kernel proper (why should they).
> 
> My fear is that there is no one true value. [...]

Do we know that?

> [...] One person complains about it, we change it, then someone else 
> complains about the new value. That would be even worse.

At that point we can still add a sysctl, if valid arguments are 
offered.

> > Which is fine for something like ftrace and other ad-hoc 
> > instrumentation that is generally very fine tuned to a given bug 
> > or given piece of hardware, but for something like the RCU 
> > implementation of the kernel - even if it's just a RT side thought 
> > of it - I'm not so sure about it.
> 
> I would argue than every case is different, and only the sysadmin 
> would know the right value. Thus, just set it to one, and if that's 
> not good enough, then the sysadmins can change it to their needs.

Well, we had really bad experience with sysctls in the past, in 
particular in the VM: with various settings exposed and distros 
'tuning' them - sometimes radically changing the way the system 
worked, confusing everyone involved.

So I'm in general opposed to sysctls for core kernel behavior - except 
for cases where we don't know better.

Instrumentation - especially instrumentation that should have been 
implemented mostly in user-space, like ftrace ;-) - is another special 
case that should stay as flexible as possible via sysctls, obviously.

Thanks,

	Ingo

  reply	other threads:[~2015-04-20 18:28 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
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 [this message]
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=20150420182831.GA19510@gmail.com \
    --to=mingo@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@linux-foundation.org \
    --cc=williams@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.