Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753089AbZAKURS (ORCPT ); Sun, 11 Jan 2009 15:17:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751840AbZAKUQy (ORCPT ); Sun, 11 Jan 2009 15:16:54 -0500 Received: from casper.infradead.org ([85.118.1.10]:60798 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754569AbZAKUQv (ORCPT ); Sun, 11 Jan 2009 15:16:51 -0500 Subject: Re: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning From: David Woodhouse To: Andi Kleen Cc: Linus Torvalds , Andrew Morton , Ingo Molnar , Harvey Harrison , "H. Peter Anvin" , Chris Mason , Peter Zijlstra , Steven Rostedt , paulmck@linux.vnet.ibm.com, Gregory Haskins , Matthew Wilcox , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich , jh@suse.cz In-Reply-To: <20090111201427.GP26290@one.firstfloor.org> References: <1231537320.5726.2.camel@brick> <20090109231227.GA25070@elte.hu> <20090110010125.GA31031@elte.hu> <20090109174158.096dee70.akpm@linux-foundation.org> <20090110030216.GW26290@one.firstfloor.org> <1231676801.25018.150.camel@macbook.infradead.org> <20090111181307.GM26290@one.firstfloor.org> <20090111201427.GP26290@one.firstfloor.org> Content-Type: text/plain Date: Sun, 11 Jan 2009 20:15:39 +0000 Message-Id: <1231704939.25018.548.camel@macbook.infradead.org> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 (2.24.2-2.fc10) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1304 Lines: 29 On Sun, 2009-01-11 at 21:14 +0100, Andi Kleen wrote: > > On the other hand (my personal opinion, not shared by everyone) is > that the ioctl switch stack issue is mostly only a problem with 4K > stacks and in the rare cases when I still run 32bit kernels > I never set that option because I consider it russian roulette > (because there undoutedly dangerous dynamic stack growth cases that > checkstack.pl doesn't flag) Isn't the ioctl switch stack issue a separate GCC bug? It was/is assigning assigning separate space for local variables which are mutually exclusive. So instead of the stack footprint of the function with the switch() being equal to the largest individual stack size of all the subfunctions, it's equal to the _sum_ of the stack sizes of the subfunctions. Even though it'll never use them all at the same time. Without that bug, it would have been harmless to inline them all. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation -- 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/