Christoph Hellwig <[EMAIL PROTECTED]> writes: > On Mon, Apr 30, 2007 at 12:26:42PM +0200, Andi Kleen wrote: > > Alan Cox <[EMAIL PROTECTED]> writes: > > > > > If this still occurs for some > > > combinations then the fix would be 8K + 4K IRQ stack, not just to use 8K > > > stack > > > > Yes i've been thinking for some time doing that would be a good idea. > > Yes, the non-irqstack case should definitively go away. And 8k > kernel stacks isn't that little given how much most 64bit architectures > have.
Actually looking at the code it would need some fixes first: /* * These should really be __section__(".bss.page_aligned") as well, but * gcc's 3.0 and earlier don't handle that correctly. */ static char softirq_stack[NR_CPUS * THREAD_SIZE] __attribute__((__aligned__(THREAD_SIZE))); static char hardirq_stack[NR_CPUS * THREAD_SIZE] __attribute__((__aligned__(THREAD_SIZE))); With 8K stacks and NR_CPUS==128 that would be 2MB statically reserved. Yuck. Really needs to be dynamically allocated. I'll take a look once the .22 big merge is done. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/