Re: Linux 2.6.29

Ingo Molnar
2009-03-28T05:07:03Z

* Andrew Morton <akpm@linux-foundation.org> wrote:

> On Thu, 26 Mar 2009 18:03:15 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > On Thu, 26 Mar 2009, Andrew Morton wrote:
> > >
> > > userspace can get closer than the kernel can.
> >
> > Andrew, that's SIMPLY NOT TRUE.
> >
> > You state that without any amount of data to back it up, as if it was some
> > kind of truism. It's not.
>
> I've seen you repeatedly fiddle the in-kernel defaults based on
> in-field experience. That could just as easily have been done in
> initscripts by distros, and much more effectively because it
> doesn't need a new kernel. That's data.
>
> The fact that this hasn't even been _attempted_ (afaik) is
> deplorable.
>
> Why does everyone just sit around waiting for the kernel to put a
> new value into two magic numbers which userspace scripts could
> have set?

Three reasons.

Firstly, this utterly does not scale.

Microsoft has built an empire on the 'power of the default settings'
- why cannot Linux kernel developers finally realize the obvious:
that setting defaults centrally is an incredibly efficient way of
shaping the end result?

The second reason is that in the past 10 years we have gone through
a couple of toxic cycles of distros trying to work around kernel
behavior by setting sysctls. That was done and then forgotten, and a
few years down the line some kernel maintainer found [related to a
bugreport] that distro X set that sysctl to value Y which now had a
different behavior and immediately chastised the distro broken and
refused to touch the bugreport and refused bugreports from that
distro from that point on.

We've seen this again, and again, and i remember 2-3 specific
examples and i know how badly this experience trickles down on the
distro side.

The end result: pretty much any tuning of kernel defaults is done
extremely reluctantly by distros. They consider kernel behavior a
domain of the kernel, and they dont generally risk going away from
the default. [ In other words, distro developers understand the
'power of defaults' a lot better than kernel developers ... ]

This is also true in the reverse direction: they dont actually mind
the kernel doing a central change of policy, if it's a general step
forward. Distro developers are very practical, and they are a lot
less hardline about the sacred Unix principle of separation of
kernel from policy.

Thirdly: the latency of getting changes to users. A new kernel is
released every 3 months. Distros are released every 6 months. A new
Firefox major version is released about once a year. A new major GCC
is released every three years.

Given the release frequency and given our goal to minimize the
latency of getting improvements to users, which of these projects is
best suited to introduce a new default value? [and no, such changes
are not generally done in minor package updates.]

Ingo