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