4k stacks in 2.6

[Ingo Molnar <mingo@elte.hu>]

* Andrea Arcangeli <andrea@suse.de> wrote:

> On Tue, May 25, 2004 at 04:10:29PM -0400, Rik van Riel wrote:
> > Fragmentation causes fork trouble (gone with the 4k stacks)
> 
> btw, the 4k stacks sounds not safe to me, most people only tested with
> 8k stacks so far, I wouldn't make that change in a production tree
> without an unstable cycle of testing in between. I'd rather risk a an
> allocation failure than a stack memory corruption.

4k stacks is a cool and useful feature and tons of effort that went into
making them as safe as possible. Sure, we couldnt fix up bin-only
modules, but all the kernel drivers are audited for stack footprint, and
many months of beta testing has gone into this as well. Anyway, if you
prefer you can turn on 8k stacks - especially if you tree has lots of
not-yet-upstream driver patches.

> x86-64 has per-irq stacks that allowed to reduce the stack size to 8k
> (which is very similar to 4k for an x86, but without per-irq stack
> it's too risky).

do you realize that the 4K stacks feature also adds a separate softirq
and a separate hardirq stack? So the maximum footprint is 4K+4K+4K, with
a clear and sane limit for each type of context, while the 2.4 kernel
has 6.5K for all 3 contexts combined. (Also, in 2.4 irq contexts pretty
much assumed that there's 2K of stack for them - leaving a de-facto 4K
stack for the process and softirq contexts.) So in fact there is more
space in 2.6 for all, and i dont really understand your fears.

	Ingo