Re: 2.6.6-rc3-mm2 (4KSTACK)

[Bartlomiej Zolnierkiewicz]

On Sunday 09 of May 2004 19:00, Bill Davidsen wrote:
> 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.

What functionality are you talking about?
We don't care about out of tree kernel code (be it GPL or Proprietary).

> 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

You don't understand what the patch is really about.

This is kernel stack not the user-space one so
this change can't brake any application.

> bug" approach comes from a well-known software company, but shouldn't be
> the way *good* software is done.

It doesn't change any kernel interface visible to user-space
and stack hungry kernel code needs fixing anyway.

Regards,
Bartlomiej

-
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/