* 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-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
