Messages in this thread | | | From | Grant Coady <> | Subject | Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers | Date | Tue, 03 Jan 2006 10:10:37 +1100 |
| |
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/
| |