cfi_{build,send_gen}_cmd bloats, how to uninline?

David Woodhouse dwmw2 at infradead.org
Tue May 6 06:03:09 EDT 2008


On Tue, 2008-05-06 at 12:53 +0300, Ilpo Järvinen wrote:
> Hi,
> 
> When doing some time ago measurements on how static inlines affect the 
> size of the kernel, I found out that uninlining cfi_{build,send_gen}_cmd 
> yield to considerable size reduction (measured with 32-bit x86, gcc 
> version 4.1.2 20070626 (Red Hat 4.1.2-13), on v2.6.25-rc2-mm1 IIRC, 
> allyesconfig minus number of manually selected DEBUG related CONFIGs):
> 
> 42 funcs, 199 +, 33328 -, diff: -33129 --- cfi_build_cmd
> 14 funcs, 365 +, 14648 -, diff: -14283 --- cfi_send_gen_cmd
> 
> ...(Because there's depency between them as cfi_send_gen_cmd includes a 
> call to cfi_build_cmd, total for both to is likely going to less than what 
> those two summed together are, uninlining cfi_send_gen_cmd might even not 
> pay off much).
> 
> I'm unsure how should the uninlining be performed in this case, 
> especially since there's some alerting comment like this:
> 
> "/* We do it this way to give the compiler a fighting chance
>     of optimising away all ..."
> 
> "* It looks too long to be inline, but in the common case it should almost all
>  * get optimised away."
> 
> ...Perhaps somebody has just assumed gcc to be more clever than it 
> actually is, I wonder if the claimed optimization was ever happening
> in practice... :-/

Were you testing with only a single interleave/bankwidth enabled, or did
you have them all supported? It's the single-geometry case where we
expect it to all fall out and the inlines to be really trivial.

I suspect that we should make the inlining optional though -- a lot of
people are building generic kernels with CFI support these days, or just
not bothering to optimise their config.

-- 
dwmw2




More information about the linux-mtd mailing list