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.
next prev 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®