public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: David Miller <davem@davemloft.net>
Cc: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
	akpm@linux-foundation.org, viro@ZenIV.linux.org.uk
Subject: Re: CONFIG_OPTIMIZE_INLINING
Date: Sun, 27 Apr 2008 10:20:10 +0200	[thread overview]
Message-ID: <20080427082010.GA13848@elte.hu> (raw)
In-Reply-To: <20080426.230807.144232984.davem@davemloft.net>


* David Miller <davem@davemloft.net> wrote:

> From: Ingo Molnar <mingo@elte.hu>
> Date: Sun, 27 Apr 2008 07:59:43 +0200
> 
> > ... as i saw no reason why this feature, which i found rather 
> > useful, should be delayed another year or so. I'd be more than happy 
> > to promote this feature back to lib/Kconfig.debug, sparc64 interest 
> > would make that a strong argument.
> 
> So you caved in to FUD in order to pad your commit and signoff count?

David, stop this nonsense already.

Had you read the lkml discussion thread i linked to:

  http://lkml.org/lkml/2008/3/3/122

... you'd realize that the first thing i did was to make it a generic 
feature. But it was claimed on lkml that this would break an unknown 
number of architectures:

| > > And what we should do is to attack the excessive wrong usage of 
| > > inlines in .c files, not messing with a global #define in a way 
| > > that the results on 24 architectures with 7 different releases of 
| > > gcc would be unpredictable.

Where were you in that thread defending my position? Andrew showed 
interest, gave me feedback and i incorporated that feedback.

I am fully willing and ready to move this feature to a generic file (via 
the patch below), in fact i implemented it that way from the get go, but 
only:

   _if other architecture maintainers want it too_

Nobody countered the "it would break other architectures" position in 
that discussion, and i'm not interested in endless bikeshed painting 
either.

lets look at a counter-example where other architecture maintainers 
showed interest: the recent bitops generalizations we did for x86 and 
extended to all other architectures. It was welcome by other maintainers 
and we did it that way. See the merge commit 9b79ed952bd734 for an 
overview of this topic:

    x86, bitops: select the generic bitmap search functions
    x86: include/asm-x86/pgalloc.h/bitops.h: checkpatch cleanups - formatting
    x86: finalize bitops unification
    x86, UML: remove x86-specific implementations of find_first_bit
    x86: optimize find_first_bit for small bitmaps
    x86: switch 64-bit to generic find_first_bit
    x86: generic versions of find_first_(zero_)bit, convert i386
    bitops: use __fls for fls64 on 64-bit archs
    generic: implement __fls on all 64-bit archs
    generic: introduce a generic __fls implementation
    x86: merge the simple bitops and move them to bitops.h
    x86, generic: optimize find_next_(zero_)bit for small constant-size bitmap
    x86, uml: fix uml with generic find_next_bit for x86
    x86: change x86 to use generic find_next_bit
    uml: Kconfig cleanup
    uml: fix build error

	Ingo

-------------------------------->
Subject: generic: optimize inlining
From: Ingo Molnar <mingo@elte.hu>
Date: Sun Apr 27 09:36:29 CEST 2008

Suggested-by: David Miller <davem@davemloft.net>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/Kconfig.debug |   12 ------------
 init/Kconfig           |   13 +++++++++++++
 2 files changed, 13 insertions(+), 12 deletions(-)

Index: linux/arch/x86/Kconfig.debug
===================================================================
--- linux.orig/arch/x86/Kconfig.debug
+++ linux/arch/x86/Kconfig.debug
@@ -355,15 +355,3 @@ config CPA_DEBUG
 
 endmenu
 
-config OPTIMIZE_INLINING
-	bool "Allow gcc to uninline functions marked 'inline'"
-	default y
-	help
-	  This option determines if the kernel forces gcc to inline the functions
-	  developers have marked 'inline'. Doing so takes away freedom from gcc to
-	  do what it thinks is best, which is desirable for the gcc 3.x series of
-	  compilers. The gcc 4.x series have a rewritten inlining algorithm and
-	  disabling this option will generate a smaller kernel there. Hopefully
-	  this algorithm is so good that allowing gcc4 to make the decision can
-	  become the default in the future, until then this option is there to
-	  test gcc for this.
Index: linux/init/Kconfig
===================================================================
--- linux.orig/init/Kconfig
+++ linux/init/Kconfig
@@ -520,6 +520,19 @@ config CC_OPTIMIZE_FOR_SIZE
 
 	  If unsure, say N.
 
+config OPTIMIZE_INLINING
+	bool "Allow gcc to uninline functions marked 'inline'"
+	default y
+	help
+	  This option determines if the kernel forces gcc to inline the functions
+	  developers have marked 'inline'. Doing so takes away freedom from gcc to
+	  do what it thinks is best, which is desirable for the gcc 3.x series of
+	  compilers. The gcc 4.x series have a rewritten inlining algorithm and
+	  disabling this option will generate a smaller kernel there. Hopefully
+	  this algorithm is so good that allowing gcc4 to make the decision can
+	  become the default in the future, until then this option is there to
+	  test gcc for this.
+
 config SYSCTL
 	bool
 

  reply	other threads:[~2008-04-27  8:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-27  4:55 CONFIG_OPTIMIZE_INLINING David Miller
2008-04-27  5:59 ` CONFIG_OPTIMIZE_INLINING Ingo Molnar
2008-04-27  6:08   ` CONFIG_OPTIMIZE_INLINING David Miller
2008-04-27  8:20     ` Ingo Molnar [this message]
2008-04-27  9:10     ` CONFIG_OPTIMIZE_INLINING SL Baur
2008-04-27  9:16       ` CONFIG_OPTIMIZE_INLINING Dave Airlie
2008-04-27  9:21         ` CONFIG_OPTIMIZE_INLINING David Miller
2008-04-27 12:13           ` CONFIG_OPTIMIZE_INLINING Ingo Molnar
2008-04-27 11:22     ` CONFIG_OPTIMIZE_INLINING Ingo Molnar
2008-04-27 17:25     ` CONFIG_OPTIMIZE_INLINING Pavel Machek
2008-04-28 10:42       ` CONFIG_OPTIMIZE_INLINING Adrian Bunk
2008-04-27  6:26   ` CONFIG_OPTIMIZE_INLINING Christoph Hellwig
2008-04-27 10:56     ` CONFIG_OPTIMIZE_INLINING Sam Ravnborg
2008-04-27  6:02 ` CONFIG_OPTIMIZE_INLINING Sam Ravnborg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080427082010.GA13848@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox