Messages in this thread | | | From | Bartlomiej Zolnierkiewicz <> | Subject | Re: 2.6.6-rc3-mm2 (4KSTACK) | Date | Sun, 9 May 2004 20:25:41 +0200 |
| |
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@gmx.net> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |