Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755402AbYH0MwW (ORCPT ); Wed, 27 Aug 2008 08:52:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754377AbYH0MwK (ORCPT ); Wed, 27 Aug 2008 08:52:10 -0400 Received: from mail-gx0-f29.google.com ([209.85.217.29]:54245 "EHLO mail-gx0-f29.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754120AbYH0MwI (ORCPT ); Wed, 27 Aug 2008 08:52:08 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=xpQfVR80pSFgZC1eMWKU76TI0ZgolvUMzhP5hV0AkURB/pDMjckwtQhXgkSLm54NCn IdcxsnP+Wm8f73doMdv22c5nwP4IkSfMYWUGFqxlBaxVO+f21SFRJ9nm7u4mGubAN7WE QbbG0IPJDru86osbVO2HCs1atf6kb7IU7PJds= Message-ID: Date: Wed, 27 Aug 2008 08:52:06 -0400 From: "Parag Warudkar" To: "Alan Cox" Subject: Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected Cc: "Adrian Bunk" , "Linus Torvalds" , "Rusty Russell" , "Alan D. Brunelle" , "Rafael J. Wysocki" , "Linux Kernel Mailing List" , "Kernel Testers List" , "Andrew Morton" , "Arjan van de Ven" , "Ingo Molnar" , linux-embedded@vger.kernel.org In-Reply-To: <20080827092528.780916bd@lxorguk.ukuu.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808261111.19205.rusty@rustcorp.com.au> <20080826183051.GB10925@cs181140183.pp.htv.fi> <20080826205916.GB11734@cs181140183.pp.htv.fi> <20080826232411.GC11734@cs181140183.pp.htv.fi> <20080827092528.780916bd@lxorguk.ukuu.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 959 Lines: 24 On Wed, Aug 27, 2008 at 4:25 AM, Alan Cox 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/