[ this email discusses only your uninline patch ]
On Sat, Dec 31, 2005 at 03:45:35PM +0100, Ingo Molnar wrote:
>
> * Adrian Bunk <[email protected]> wrote:
>
> > On Fri, Dec 30, 2005 at 08:49:16AM +0100, Ingo Molnar wrote:
> > >
> > > * Tim Schmielau <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
