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

[Adrian Bunk <bunk@stusta.de>]

On Wed, Dec 28, 2005 at 12:46:37PM +0100, Ingo Molnar wrote:
> this patchset (for the 2.6.16 tree) consists of two patches:
> 
>   gcc-no-forced-inlining.patch
>   gcc-unit-at-a-time.patch
> 
> the purpose of these patches is to reduce the kernel's .text size, in 
> particular if CONFIG_CC_OPTIMIZE_FOR_SIZE is specified. The effect of 
> the patches on x86 is:
> 
>     text    data     bss     dec     hex filename
>  3286166  869852  387260 4543278  45532e vmlinux-orig
>  3194123  955168  387260 4536551  4538e7 vmlinux-inline
>...

The most interesting question is:
Which object files do these savings come from

We have two cases in the kernel:
- header files where forced inlining is required
- C files where forced inlining is nearly always wrong

The classical example are functions some marked as "inline" when they 
where tiny and had one caller, but now are huge and have many callers.

An interesting number would be the space saving after doing some kind of 
s/inline//g in all .c files.

> unit-at-a-time still increases the kernel stack footprint somewhat (by 
> about 5% in the CC_OPTIMIZE_FOR_SIZE case), but not by the insane degree 
> gcc3 used to, which prompted the original -fno-unit-at-a-time addition.
>...

Please hold off this patch.

I do already plan to look at this after the smoke has cleared after the 
4k stacks issue. I want to avoid two different knobs both with negative 
effects on stack usage (currently CONFIG_4KSTACKS=y, and after your 
patch gcc >= 4.0) giving a low testing coverage of the worst cases.

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