[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080827142142.303cdba8@lxorguk.ukuu.org.uk>
Date: Wed, 27 Aug 2008 14:21:42 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: "Parag Warudkar" <parag.lkml@...il.com>
Cc: "Adrian Bunk" <bunk@...nel.org>,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"Rusty Russell" <rusty@...tcorp.com.au>,
"Alan D. Brunelle" <Alan.Brunelle@...com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"Kernel Testers List" <kernel-testers@...r.kernel.org>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Arjan van de Ven" <arjan@...ux.intel.com>,
"Ingo Molnar" <mingo@...e.hu>, linux-embedded@...r.kernel.org
Subject: Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c -
bisected
> By your logic though, XFS on x86 should work fine with 4K stacks -
> many will attest that it does not and blows up due to stack issues.
>
> I have first hand experiences of things blowing up with deep call
> chains when using 4K stacks where 8K worked just fine on same
> workload.
>
> So there is definitely some other problem with 4K stacks.
Nothing of the sort. If it blows up with a 4K stack it will almost
certainly blow up with an 8K stack *eventually* - when a heavy stack usage
coincides with a heavy stack using IRQ handler.
You won't catch it in simple testing, you won't catch it in trivial
simulation and it'll be incredibly hard to reproduce. Not the kind of bug
you want in a production system really. IRQ stacks make things much more
predictable.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists