Messages in this thread | | | Date | Wed, 26 May 2004 12:33:03 +0200 | From | Ingo Molnar <> | Subject | 4k stacks in 2.6 |
| |
* 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 - 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/
| |