Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754327AbZAIQjS (ORCPT ); Fri, 9 Jan 2009 11:39:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752396AbZAIQi7 (ORCPT ); Fri, 9 Jan 2009 11:38:59 -0500 Received: from terminus.zytor.com ([198.137.202.10]:46545 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752137AbZAIQi5 (ORCPT ); Fri, 9 Jan 2009 11:38:57 -0500 Message-ID: <49677CB1.3030701@zytor.com> Date: Fri, 09 Jan 2009 08:34:57 -0800 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Ingo Molnar CC: jim owens , Linus Torvalds , Chris Mason , Peter Zijlstra , Steven Rostedt , paulmck@linux.vnet.ibm.com, Gregory Haskins , Matthew Wilcox , Andi Kleen , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich Subject: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact References: <20090108141808.GC11629@elte.hu> <1231426014.11687.456.camel@twins> <1231434515.14304.27.camel@think.oraclecorp.com> <20090108183306.GA22916@elte.hu> <496648C7.5050700@zytor.com> <20090109130057.GA31845@elte.hu> <49675920.4050205@hp.com> <20090109153508.GA4671@elte.hu> In-Reply-To: <20090109153508.GA4671@elte.hu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1247 Lines: 33 Ingo Molnar wrote: > > My goal is to make the kernel smaller and faster, and as far as the > placement of 'inline' keywords goes, i dont have too strong feelings about > how it's achieved: they have a certain level of documentation value > [signalling that a function is _intended_ to be lightweight] but otherwise > they are pretty neutral attributes to me. > As far as naming is concerned, gcc effectively supports four levels, which *currently* map onto macros as follows: __always_inline Inline unconditionally inline Inlining hint Standard heuristics noinline Uninline unconditionally A lot of noise is being made about the naming of the levels (and I personally believe we should have a different annotation for "inline unconditionally for correctness" and "inline unconditionally for performance", as a documentation issue), but those are the four we get. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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/