Re: 2.6.6-rc3-mm2 (4KSTACK)

[Bill Davidsen]

Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 05 of May 2004 22:31, Bill Davidsen wrote:
>
> > Andrew Morton wrote:
> >
> > > Dominik Karall <dominik.karall@xxxxxxx> wrote:
> > >
> > > > On Wednesday 05 May 2004 10:31, you wrote:
> > > >
> > > > > +make-4k-stacks-permanent.patch
> > > > >
> > > > > Fill my inbox.
> > > >
> > > > Hi Andrew!
> > > >
> > > > Is there any reason why this patch was applied? Because NVidia users
> > > > can't work with the original drivers now without removing this patch
> > > > every time.
> > >
> > > We need to push this issue along quickly.  The single-page stack
> > > generally gives us a better kernel and having the stack size configurable
> > > creates pain.
> >
> > Add my voice to those who don't think 4k stacks are a good idea as a
> > default, they break some things and seem to leave other paths (as others
> > have noted) on the edge. I'm not sure what you have in mind as a "better
> > kernel" but I'd rather have a worse kernel and not have to check 4k
> > stack as a possible problem before looking at other things if I get bad
> > behaviour.
> >
> > Reliability first, performance later. We've lived with the config for a
> > while, pain there is better than pain at runtime.
>
>
> Opposite opinion here.
>
> If you want 100% reliability you shouldn't use -mm in the first place.
>
> Making 4kb stacks default in -mm is very good idea so it will get necessary
> testing and fixing before being integrated into mainline.
>
> Please also note that users of binary only modules always have choice:
> - new kernels without binary only modules
> - old kernels with binary only modules
>
> It is really that simple.

No it's not that simple, this has nothing to do with binary modules, and 
everything to do with not making 4k stack the only available 
configuration in 2.6. Options are fine, but in a stable kernel series I 
don't think think that the default should change part way into the 
series, and certainly the availability of the original functionality 
shouldn't go away, which is what I read AKPMs original post to state as 
the goal.

Making changes to the kernel which will break existing applications 
seems to be the opposite of "stable." People who want a new kernel for 
fixes don't usually want to have to upgrade and/or rewrite their 
applications. The "we change the system interface everything we fix a 
bug" approach comes from a well-known software company, but shouldn't be 
the way *good* software is done.

--
bill davidsen <davidsen@xxxxxxx>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979
-
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/