Re: 2.6.6-rc3-mm2 (4KSTACK)

From: Bill Davidsen
Date: Sun May 09 2004 - 11:55:14 EST

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:


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

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
Please read the FAQ at