![]() | ||||||||||
Messages in this thread |
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/ | |||||||||
| Last update: 2005-03-22 13:03 [from the cache] ©2003-2008 | ||||||||||