Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758251AbZAIVsj (ORCPT ); Fri, 9 Jan 2009 16:48:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758064AbZAIVsW (ORCPT ); Fri, 9 Jan 2009 16:48:22 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:46195 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757087AbZAIVsU (ORCPT ); Fri, 9 Jan 2009 16:48:20 -0500 Date: Fri, 9 Jan 2009 13:46:55 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Ingo Molnar cc: "H. Peter Anvin" , Andi Kleen , Chris Mason , Peter Zijlstra , Steven Rostedt , paulmck@linux.vnet.ibm.com, Gregory Haskins , Matthew Wilcox , Andrew Morton , 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 In-Reply-To: <20090109213442.GA20051@elte.hu> Message-ID: References: <1231434515.14304.27.camel@think.oraclecorp.com> <20090108183306.GA22916@elte.hu> <20090108190038.GH496@one.firstfloor.org> <4966AB74.2090104@zytor.com> <20090109133710.GB31845@elte.hu> <20090109204103.GA17212@elte.hu> <20090109213442.GA20051@elte.hu> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1384 Lines: 36 On Fri, 9 Jan 2009, Ingo Molnar wrote: > > - Perhaps we could introduce a name for the first category: __must_inline? > __should_inline? Not because it wouldnt mean 'always', but because it is > 'always inline' for another reason than the correctless __always_inline. I think you're thinking about this the wrong way. "inline" is a pretty damn strong hint already. If you want a weaker one, make it _weaker_ instead of trying to use superlatives like "super_inline" or "must_inline" or whatever. So I'd suggest: - keep "inline" as being a strong hint. In fact, I'd suggest it not be a hint at all - when we say "inline", we mean it. No ambiguity _anywhere_, and no need for idiotic "I really really REALLY mean it" versions. - add a "maybe_inline" or "inline_hint" to mean that "ok, compiler, maybe this is worth inlining, but I'll leave the final choice to you". That would get rid of the whole rationale for OPTIMIZE_INLINING=y, because at that point, it's no longer potentially a correctness issue. At that point, if we let gcc optimize things, it was a per-call-site conscious decision. Linus -- 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/