mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Adrian Bunk <bunk@kernel.org>, Sam Ravnborg <sam@ravnborg.org>,
	Alexey Starikovskiy <aystarik@gmail.com>,
	lenb@kernel.org, astarikovskiy@suse.de,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [patch] x86: phase out forced inlining
Date: Mon, 3 Mar 2008 07:01:17 -0800	[thread overview]
Message-ID: <20080303070117.0325e77a@laptopd505.fenrus.org> (raw)
In-Reply-To: <20080303121335.GA15381@elte.hu>

On Mon, 3 Mar 2008 13:13:35 +0100
Ingo Molnar <mingo@elte.hu> wrote:


> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > > > no, what we should nuke is this always_inline definition. That
> > > > was always the intention of FORCED_INLINE, and the removal of 
> > > > FORCED_INLINE was to _remove the forcing_, not to make it 
> > > > unconditional.
> > > 
> > > It was always unconditional, and neither adding, toggling nor 
> > > removing of CONFIG_FORCED_INLINING changed this invariant.
> > > 
> > > 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.
> > 
> > i see, so you never properly reported and fixed it because you
> > prefer a 1000 small crappy changes over one change. You could have 
> > significantly contributed to truly making Linux smaller, but you 
> > decided not to do it.
> > 
> > and i disagree with your notion that flipping it around is risky in 
> > any unacceptable or unmanageable way. It has far less risks on the 
> > compiler than say CONFIG_CC_OPTIMIZE_FOR_SIZE. It has far less
> > risks than changing to a new compiler version. Why you think it's 
> > "unpredictable" is a mystery to me.
> > 
> > It almost seems to me you were happy with having that bug in the 
> > kernel? Please tell me that i'm wrong about that impression!
> > 
> > i'll reinstate this .config option and let it do the right thing. 
> > Forced inlining was supposed to be _phased out_, not phased in.
> 
> i just implemented the trivial fix below and it gave me a massive,
> 2.3% text size reduction (!) on a typical .config. That's more than
> 120K shaved off the vmlinux.
> 
> Why, despite being aware of this bug, you never fixed this properly
> is a mystery to me - this is more .text size savings than you have
> done so far with all your uninlining patches of the past few years
> combined, and it's probably more than you could have achieved in the
> next 5 years.
> 
> 	Ingo
> 
> ---------------------->
> Subject: x86: phase out forced inlining
> From: Ingo Molnar <mingo@elte.hu>
> Date: Mon Mar 03 12:38:52 CET 2008
> 
> allow gcc to optimize the kernel image's size by uninlining
> functions that have been marked 'inline'. Previously gcc was
> forced by Linux to always-inline these functions via a gcc
> attribute:
> 
>  #define inline	inline __attribute__((always_inline))
> 
> Especially when the user has already selected
> CONFIG_OPTIMIZE_FOR_SIZE=y this can make a huge difference in
> kernel image size (using a standard Fedora .config):
> 
>    text    data     bss     dec           hex filename
>    5613924  562708 3854336 10030968    990f78 vmlinux.before
>    5486689  562708 3854336  9903733    971e75 vmlinux.after
> 
> that's a 2.3% text size reduction (!).
> 
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  arch/x86/Kconfig.debug            |   13 +++++++++++++
>  arch/x86/configs/i386_defconfig   |    1 +
>  arch/x86/configs/x86_64_defconfig |    1 +
>  include/linux/compiler-gcc.h      |   12 +++++++++---
>  4 files changed, 24 insertions(+), 3 deletions(-)
> 
> Index: linux-x86.q/arch/x86/Kconfig.debug
> ===================================================================
> --- linux-x86.q.orig/arch/x86/Kconfig.debug


eh.. we ALREADY HAD THIS.
someone seems to have removed this wronly; not forcing inline should have been
the default after the removal (in 2.6.25-rc)!

So lets fix it that way, rather than putting the config option back under a different name.

  parent reply	other threads:[~2008-03-03 15:02 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-01 16:19 [2.6 patch] acpi/battery.c: make 2 functions static Adrian Bunk
2008-03-01 18:26 ` Alexey Starikovskiy
2008-03-01 18:35   ` Adrian Bunk
2008-03-01 18:42     ` Alexey Starikovskiy
2008-03-01 18:45       ` Adrian Bunk
2008-03-03  8:57     ` Ingo Molnar
2008-03-03  9:13       ` Adrian Bunk
2008-03-03  9:17         ` Ingo Molnar
2008-03-03  9:31           ` Sam Ravnborg
2008-03-03  9:48             ` Adrian Bunk
2008-03-03 10:39             ` Ingo Molnar
2008-03-03 11:34               ` Adrian Bunk
2008-03-03 11:45                 ` Ingo Molnar
2008-03-03 12:02                   ` Adrian Bunk
2008-03-03 12:10                     ` Ingo Molnar
2008-03-03 12:29                       ` Adrian Bunk
2008-03-03 12:50                         ` Ingo Molnar
2008-03-03 14:54                           ` Adrian Bunk
2008-03-03 15:01                             ` Adrian Bunk
2008-03-04 13:16                             ` Ingo Molnar
2008-03-04 13:47                               ` Adrian Bunk
2008-03-04 14:22                                 ` Ingo Molnar
2008-03-04 14:36                                   ` Jörn Engel
2008-03-04 14:45                                     ` Ingo Molnar
2008-03-03 12:13                   ` [patch] x86: phase out forced inlining Ingo Molnar
2008-03-03 14:56                     ` Sam Ravnborg
2008-03-04 16:46                       ` Ingo Molnar
2008-03-04 18:07                         ` Harvey Harrison
2008-03-04 18:09                           ` H. Peter Anvin
2008-03-04 18:14                             ` Harvey Harrison
2008-03-04 18:18                             ` Harvey Harrison
2008-03-03 15:01                     ` Arjan van de Ven [this message]
2008-03-03 15:58                       ` Harvey Harrison
2008-03-04  6:42                     ` Andrew Morton
2008-03-04  7:32                       ` Ingo Molnar
2008-03-04  8:00                         ` Andrew Morton
2008-03-04  9:50                           ` Andi Kleen
2008-03-04  8:03                       ` Sam Ravnborg
2008-03-04  8:38                         ` Andrew Morton
2008-03-03  9:45           ` [2.6 patch] acpi/battery.c: make 2 functions static Adrian Bunk

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=20080303070117.0325e77a@laptopd505.fenrus.org \
    --to=arjan@infradead.org \
    --cc=astarikovskiy@suse.de \
    --cc=aystarik@gmail.com \
    --cc=bunk@kernel.org \
    --cc=hpa@zytor.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=sam@ravnborg.org \
    --cc=tglx@linutronix.de \
    /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

all inboxes | Powered by JetHome®