lkml.org 
[lkml]   [2015]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT RFC PULL rcu/urgent] Prevent Kconfig from asking pointless questions

* 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


\
 
 \ /
  Last update: 2015-04-20 20:41    [W:0.089 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site