[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f7848160808270552u2ee66167x912a68e0bf8b25bf@mail.gmail.com>
Date: Wed, 27 Aug 2008 08:52:06 -0400
From: "Parag Warudkar" <parag.lkml@...il.com>
To: "Alan Cox" <alan@...rguk.ukuu.org.uk>
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
On Wed, Aug 27, 2008 at 4:25 AM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> You have a good point that aiming at 4kB makes 8kB a very safe choice.
>
> Not really no - we use separate IRQ stacks in 4K but not 8K mode on
> x86-32. That means you've actually got no more space if you are unlucky
> with the timing of events. The 8K mode is merely harder to debug.
>
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.
Thanks
Parag
--
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