Re: [patch] x86: phase out forced inlining

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


> 
> * Ingo Molnar <mingo@xxxxxxx> 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@xxxxxxx>
> 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@xxxxxxx>
> ---
>  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.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux