Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753513AbYHZXZQ (ORCPT ); Tue, 26 Aug 2008 19:25:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752083AbYHZXZB (ORCPT ); Tue, 26 Aug 2008 19:25:01 -0400 Received: from smtp4.pp.htv.fi ([213.243.153.38]:58621 "EHLO smtp4.pp.htv.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751844AbYHZXZA (ORCPT ); Tue, 26 Aug 2008 19:25:00 -0400 Date: Wed, 27 Aug 2008 02:24:11 +0300 From: Adrian Bunk To: Linus Torvalds Cc: 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 Subject: Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected Message-ID: <20080826232411.GC11734@cs181140183.pp.htv.fi> References: <48B313E0.1000501@hp.com> <200808261111.19205.rusty@rustcorp.com.au> <20080826183051.GB10925@cs181140183.pp.htv.fi> <20080826205916.GB11734@cs181140183.pp.htv.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1745 Lines: 50 On Tue, Aug 26, 2008 at 02:04:57PM -0700, Linus Torvalds wrote: > > > On Tue, 26 Aug 2008, Adrian Bunk wrote: > > > > If you think we have too many stacksize problems I'd suggest to consider > > removing the choice of 4k stacks on i386, sh and m68knommu instead of > > using -fno-inline-functions-called-once: > > Don't be silly. That makes the problem _worse_. > > We're much better off with a 1% code-size reduction than forcing big > stacks on people. The 4kB stack option is also a good way of saying "if it > works with this, then 8kB is certainly safe". >... You implicitely assume both would solve the same problem. While 4kB stacks are something we anyway never got 100% working, the cases where gcc inlining functions causes a critical increase in stack usage are usually not that hard to find, and once found the fix is trivial. We should anyway monitor stack usages better since we have frequent programming errors in this area, and problems caused by gcc can this way be detected en passant. You have a good point that aiming at 4kB makes 8kB a very safe choice. But I do not think the problem you'd solve with -fno-inline-functions-called-once is big enough to warrant the size increase it causes. > Linus cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/