User: Password:
|
|
Subscribe / Log in / New account

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

From:  Ingo Molnar <mingo-AT-elte.hu>
To:  Adrian Bunk <bunk-AT-stusta.de>
Subject:  Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers
Date:  Mon, 2 Jan 2006 11:37:21 +0100
Cc:  Tim Schmielau <tim-AT-physik3.uni-rostock.de>, Arjan van de Ven <arjan-AT-infradead.org>, Linus Torvalds <torvalds-AT-osdl.org>, Dave Jones <davej-AT-redhat.com>, Andrew Morton <akpm-AT-osdl.org>, lkml <linux-kernel-AT-vger.kernel.org>, mpm-AT-selenic.com
Archive-link:  Article, Thread


* Adrian Bunk <bunk@stusta.de> wrote:

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

we can have two types of breakages:

 - stuff wont build if not always_inline. Really easy to find and fix.

 - stuff wont work at all (e.g. vsyscalls) because they have some
   unspecified reliance on gcc's code output. Such code Is Bad anyway,
   and the breakage is still clear: the vsyscalls wont work at all, it's
   quickly found, the appropriate always_inline is inserted, and the
   incident is forgotten.

talking about 'safer' or 'risky' in this context is misleading, these 
are very clear symptoms which are easy to fix.

[ If you didnt talk about this uninline patch in the "we have to wait 
  one year" comment then please clarify that - all that came through to 
  me was some vague "lets wait with this" message, and it wasnt clear 
  (to me) which patch it applied to and why. ]

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

sure, that's another thing to do, but it's also clear that there's no 
reason to force inlines in the -Os case.

There are 22,000+ inline functions in the kernel right now (inlined 
about a 100,000 times), and we'd have to change _thousands_ of them. 
They are causing an unjustified code bloat of somewhere around 20-30%. 
(some of them are very much justified, especially in core kernel code)

to say it loud and clear again: our current way of handling inlines is 
_FUNDAMENTALLY BROKEN_. To me this means that fundamental changes are 
needed for the _mechanics_ and meaning of inlines. We default to 'always 
inline' which has a current information to noise ratio of 1:10 perhaps.  
My patch changes the mechanics and meaning of inlines, and pretty much 
anything else but a change to the meaning of inlines will still result 
in the same scenario occuring over and over again.

	Ingo


(Log in to post comments)


Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds