Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers

[Adrian Bunk <bunk@stusta.de>]

[ this email discusses only your uninline patch ]

On Sat, Dec 31, 2005 at 03:45:35PM +0100, Ingo Molnar wrote:
> 
> * Adrian Bunk <bunk@stusta.de> wrote:
> 
> > On Fri, Dec 30, 2005 at 08:49:16AM +0100, Ingo Molnar wrote:
> > > 
> > > * Tim Schmielau <tim@physik3.uni-rostock.de> wrote:
> > > 
> > > > What about the previous suggestion to remove inline from *all* static 
> > > > inline functions in .c files?
> > > 
> > > i think this is a way too static approach. Why go from one extreme to 
> > > the other, when my 3 simple patches (which arguably create a more 
> > > flexible scenario) gives us savings of 7.7%?
> > 
> > This point only discusses the inline change, which were (without 
> > unit-at-a-time) in your measurements 2.9%.
> > 
> > Your patch might be simple, but it also might have side effects in 
> > cases where we _really_ want the code forced to be inlined. How simple 
> > is it to prove that your uninline patch doesn't cause a subtle 
> > breakage somewhere?
> 
> it's quite simple: run the latency tracer with stack-trace debugging 
> enabled, and it will measure the worst-case stack footprint that is 
> triggered on that system. Obviously any compiler version change or 
> option change can cause problems, there's nothing new about it - and 
> it's not realistic to wait one year for changes like that. If you have 
> to wait that long, you are testing it the wrong way.

What are you talking about?

You sent two different patches:
1. uninline
2. unit-at-a-time for i386

These are two separate patches that should be discussed separately.

Your answer regarding your second patch does't fit in any way my email 
regarding your first patch.

Your uninline patch shouldn't cause any regressions regarding stack 
footprint, and stack usage is not what I was talking about.

My email was about things like Andi's example of the x86-64 vsyscall 
code where we really need inlining, and due to your proposed inline 
semantics change there might be breakages if an __always_inline is 
forgotten at a place where it was required.

Your uninline patch might be simple, but the safe way would be Arjan's 
approach to start removing all the buggy inline's from .c files.

> 	Ingo

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
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/