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

[Grant Coady <grant_lkml@dodo.com.au>]

On Mon, 02 Jan 2006 23:56:23 +0100, Arjan van de Ven <arjan@infradead.org> wrote:

>I proposed the following chunks:
>
>Adds a bit of text to Documentation/Codingstyle to state that
>inlining everything "just because" is a bad idea
>
>Signed-off-by: Arjan van de Ven <arjan@infradead.org>
>
>diff -purN linux-2.6.15-rc6/Documentation/CodingStyle linux-2.6.15-rc6-deinline/Documentation/CodingStyle
>--- linux-2.6.15-rc6/Documentation/CodingStyle	2005-10-28 02:02:08.000000000 +0200
>+++ linux-2.6.15-rc6-deinline/Documentation/CodingStyle	2005-12-30 13:31:13.000000000 +0100
>@@ -344,7 +344,7 @@ Remember: if another thread can find you
> have a reference count on it, you almost certainly have a bug.
> 
> 
>-		Chapter 11: Macros, Enums, Inline functions and RTL
>+		Chapter 11: Macros, Enums and RTL
> 
> Names of macros defining constants and labels in enums are capitalized.
> 
>@@ -429,7 +429,35 @@ from void pointer to any other pointer t
> language.
> 
> 
>-		Chapter 14: References
>+		Chapter 14: The inline disease
>+
>+There appears to be a common misperception that gcc has a magic "make me
>+faster" ricing option called "inline". While the use of inlines can be
          ^^^^^^--?? not sure what this is
>+appropriate (for example as a means of replacing macros, see Chapter 11), it
>+very often is not. Abundant use of the inline keyword leads to a much bigger
>+kernel, which in turn slows the system as a whole down, due to a bigger
>+icache footprint for the CPU and simply because there is less memory
>+available for the pagecache. Just think about it; a pagecache miss causes a
>+disk seek, which easily takes 5 miliseconds. There are a LOT of cpu cycles
>+that can go into these 5 miliseconds.
>+
>+A reasonable rule of thumb is to not put inline at functions that have more
>+than 3 lines of code in them. An exception to this rule are the cases where
>+a parameter is known to be a compiletime constant, and as a result of this
>+constantness you *know* the compiler will be able to optimize most of your
>+function away at compile time. For a good example of this later case, see
>+the kmalloc() inline function.
>+
>+Often people argue that adding inline to functions that are static and used
>+only once is always a win since there is no space tradeoff. While this is
>+technically correct, gcc is capable of inlining these automatically without
>+help, and the maintenance issue of removing the inline when a second user
>+appears outweighs the potential value of the hint that tells gcc to do
>+something it would have done anyway.

Seems sane, reasonable and mostly readable to me, thank you.

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