Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757384AbZAIGBo (ORCPT ); Fri, 9 Jan 2009 01:01:44 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753594AbZAIGBR (ORCPT ); Fri, 9 Jan 2009 01:01:17 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:37991 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756911AbZAIGBP (ORCPT ); Fri, 9 Jan 2009 01:01:15 -0500 Date: Thu, 8 Jan 2009 22:00:28 -0800 From: Andrew Morton To: Andi Kleen Cc: "H. Peter Anvin" , Harvey Harrison , Ingo Molnar , Linus Torvalds , 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 Subject: Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning Message-Id: <20090108220028.3b73a509.akpm@linux-foundation.org> In-Reply-To: <20090109033531.GR496@one.firstfloor.org> References: <1231408718.11687.400.camel@twins> <20090108141808.GC11629@elte.hu> <1231426014.11687.456.camel@twins> <1231434515.14304.27.camel@think.oraclecorp.com> <20090108183306.GA22916@elte.hu> <1231444786.5715.8.camel@brick> <4966ABF9.9080409@zytor.com> <20090109033531.GR496@one.firstfloor.org> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.5; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1524 Lines: 56 On Fri, 9 Jan 2009 04:35:31 +0100 Andi Kleen wrote: > On Thu, Jan 08, 2009 at 05:44:25PM -0800, H. Peter Anvin wrote: > > Harvey Harrison wrote: > > >> > > >> We might still try the second or third options, as i think we shouldnt go > > >> back into the business of managing the inline attributes of ~100,000 > > >> kernel functions. > > > > > > Or just make it clear that inline shouldn't (unless for a very good reason) > > > _ever_ be used in a .c file. > > > > > > > The question is if that would produce acceptable quality code. In > > theory it should, but I'm more than wondering if it really will. > > I actually often use noinline when developing code simply because it > makes it easier to read oopses when gcc doesn't inline ever static > (which it normally does if it only has a single caller). You know > roughly where it crashed without having to decode the line number. > > I believe others do that too, I notice it's all over btrfs for example. > Plus there is the problem where foo() { char a[1000]; } bar() { char a[1000]; } zot() { foo(); bar(); } uses 2000 bytes of stack. Fortunately scripts/checkstack.pl can find these. If someone runs it. With the right kconfig settings. And with the right compiler version. -- 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/