Re: [GIT RFC PULL rcu/urgent] Prevent Kconfig from asking pointless questions

[Ingo Molnar]

* Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:

> On Mon, 20 Apr 2015 20:09:04 +0200
> Ingo Molnar <mingo@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/