Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754882AbZAKR66 (ORCPT ); Sun, 11 Jan 2009 12:58:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751836AbZAKR6q (ORCPT ); Sun, 11 Jan 2009 12:58:46 -0500 Received: from one.firstfloor.org ([213.235.205.2]:39457 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751544AbZAKR6p (ORCPT ); Sun, 11 Jan 2009 12:58:45 -0500 Date: Sun, 11 Jan 2009 19:13:07 +0100 From: Andi Kleen To: David Woodhouse Cc: Andi Kleen , Andrew Morton , Ingo Molnar , Linus Torvalds , 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 Subject: Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning Message-ID: <20090111181307.GM26290@one.firstfloor.org> References: <20090109213442.GA20051@elte.hu> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1231676801.25018.150.camel@macbook.infradead.org> User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1360 Lines: 35 On Sun, Jan 11, 2009 at 12:26:41PM +0000, David Woodhouse wrote: > - Unconditionally have 'inline' meaning 'always_inline'. If we say it, > we should mean it. > > - Resist the temptation to use -fno-inline-functions. Allow GCC to > inline other things if it wants to. The proposal was to use -fno-inline-functions-called-once (but the resulting numbers were not promising) We've never allowed gcc to inline any other functions not marked inline explicitely because that's not included in -O2. > - Reduce the number of unnecessary 'inline' markers, and have a policy > that the use of 'inline' should be accompanied by either a GCC PR# > or an explanation of why we couldn't reasonably have expected GCC to > get this particular case right. > > - Have a similar policy of PR# or explanation for 'uninline' too. > > I don't think we should just give up on GCC ever getting it right. That > way lies madness. As we've often found in the past. It sounds like you're advocating to set -O3/-finline-functions by default. Not sure that's a good idea. -Andi -- ak@linux.intel.com -- 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/