After applying Arjan's noline patch (http://www.fenrus.org/noinlin), I
see almost a 10% reduction in the size of .text (against 2.6.15-rc6)
with no apparent errors and no reduction in functionality:
$ size vmlinux.*
text data bss dec hex filename
2578246 462000 479920 3520166 35b6a6 vmlinux.inline
2327319 462000 479920 3269239 31e277 vmlinux.noinline
So, from where I sit, it seems like a reasonable patch to field test in
-mm.
Kurt
--
Blood is thicker than water, and much tastier.
On Sun, 2006-01-01 at 10:57 -0500, Kurt Wall wrote:
> After applying Arjan's noline patch (http://www.fenrus.org/noinline), I
> see almost a 10% reduction in the size of .text (against 2.6.15-rc6)
wow that's a lot, more than I expected actually....
On Sun, Jan 01, 2006 at 05:12:33PM +0100, Arjan van de Ven took 0 lines to write:
> On Sun, 2006-01-01 at 10:57 -0500, Kurt Wall wrote:
> > After applying Arjan's noline patch (http://www.fenrus.org/noinline), I
> > see almost a 10% reduction in the size of .text (against 2.6.15-rc6)
>
> wow that's a lot, more than I expected actually....
And that's with gcc 3.4.4. As soon as I build a 4.x, I'll post numbers
for that, too.
Kurt
--
Every journalist has a novel in him, which is an excellent place for it.
On Sun, Jan 01, 2006 at 10:57:10AM -0500, Kurt Wall took 0 lines to write:
> After applying Arjan's noline patch (http://www.fenrus.org/noinlin), I
> see almost a 10% reduction in the size of .text (against 2.6.15-rc6)
> with no apparent errors and no reduction in functionality:
>
> $ size vmlinux.*
> text data bss dec hex filename
> 2578246 462000 479920 3520166 35b6a6 vmlinux.inline
> 2327319 462000 479920 3269239 31e277 vmlinux.noinline
The above was built with gcc 3.4.4. With gcc 4.0.2 on the same config:
$ size vmlinux.402.*
text data bss dec hex filename
2626474 461856 479984 3568314 3672ba vmlinux.402.inline
2313578 461800 479984 3255362 31ac42 vmlinux.402.noinline
An 11.9% size reduction in .text. What I also notice is the 4.0.2
appears to inline more aggressively than 3.4.4 because the same
config is almost 50K larger in the inline case when compiled with gcc
3.4.4. the "noinline" cases were built with Arjan's patch and
CONFIG_CC_OPTIMIZE_FOR_SIZE; the "inline" kernels were built,
obviously, without the patch and without CONFIG_CC_OPTIMIZE_FOR_SIZE.
Kurt
--
Fifth Law of Procrastination:
Procrastination avoids boredom; one never has the feeling that
there is nothing important to do.
Kurt Wall wrote:
> the "noinline" cases were built with Arjan's patch and
> CONFIG_CC_OPTIMIZE_FOR_SIZE; the "inline" kernels were built,
> obviously, without the patch and without CONFIG_CC_OPTIMIZE_FOR_SIZE.
Wait, so how do we know if its GCC's -Os that caused the reduction in .text
size, or the noinline patch ... ?
To get actual results, you should either take OPTIMIZE_FOR_SIZE out the equation
or use it on the other kernel as well...
--
[Name ] :: [Matan I. Peled ]
[Location ] :: [Israel ]
[Public Key] :: [0xD6F42CA5 ]
[Keyserver ] :: [keyserver.kjsl.com]
encrypted/signed plain text preferred
* Kurt Wall <[email protected]> wrote:
> After applying Arjan's noline patch (http://www.fenrus.org/noinlin), I
> see almost a 10% reduction in the size of .text (against 2.6.15-rc6)
> with no apparent errors and no reduction in functionality:
just to make sure: this was with -Os _also_ turned on, right? So what
you measured was the effect of Arjan's patch plus -Os, combined,
correct?
if yes you should measure the two effects in isolation, like the vmlinux
numbers i posted. Every patch applied and every change to .config
options must be measured separately, to get valid results. This doesnt
invalidate your raw vmlinux measurements - you simply need to add a
"Arjan's patch applied but no -Os turned on" number - but it does
invalidate your conclusion quoted above.
Ingo
On Mon, Jan 02, 2006 at 12:03:28PM +0200, Matan Peled took 0 lines to write:
> Kurt Wall wrote:
> >the "noinline" cases were built with Arjan's patch and
> >CONFIG_CC_OPTIMIZE_FOR_SIZE; the "inline" kernels were built,
> >obviously, without the patch and without CONFIG_CC_OPTIMIZE_FOR_SIZE.
>
> Wait, so how do we know if its GCC's -Os that caused the reduction in .text
> size, or the noinline patch ... ?
Right, I need to isolate the effects of each variable. Results for gcc
3.4.4 and 4.0.2, built with CONFIG_CC_OPTIMIZE_FOR_SIZE enabled, appear
below. Pardon the bad methodology.
$ size vmlinux.*
text data bss dec hex filename
2333474 461848 479920 3275242 31f9ea vmlinux.344.inline
2327319 462000 479920 3269239 31e277 vmlinux.344.noinline
2319085 461608 479984 3260677 31c105 vmlinux.402.inline
2313578 461800 479984 3255362 31ac42 vmlinux.402.noinline
Kurt
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer
On Mon, Jan 02, 2006 at 12:04:04PM +0100, Ingo Molnar took 0 lines to write:
>
> * Kurt Wall <[email protected]> wrote:
>
> > After applying Arjan's noline patch (http://www.fenrus.org/noinlin), I
> > see almost a 10% reduction in the size of .text (against 2.6.15-rc6)
> > with no apparent errors and no reduction in functionality:
>
> just to make sure: this was with -Os _also_ turned on, right? So what
> you measured was the effect of Arjan's patch plus -Os, combined,
> correct?
Yes. And it was a faulty approach. I've posted new results with the
effects of Arjan's patch. CONFIG_CC_OPTIMIZE_FOR_SIZE was enabled for
all kernels.
> if yes you should measure the two effects in isolation, like the vmlinux
> numbers i posted. Every patch applied and every change to .config
> options must be measured separately, to get valid results. This doesnt
> invalidate your raw vmlinux measurements - you simply need to add a
> "Arjan's patch applied but no -Os turned on" number - but it does
> invalidate your conclusion quoted above.
Quite so. I'm working on the "no -Os" case now.
Kurt
--
Alden's Laws:
(1) Giving away baby clothes and furniture is the major cause
of pregnancy.
(2) Always be backlit.
(3) Sit down whenever possible.
On Mon, Jan 02, 2006 at 10:14:29AM -0500, Kurt Wall took 0 lines to write:
>
> Right, I need to isolate the effects of each variable. Results for gcc
> 3.4.4 and 4.0.2, built with CONFIG_CC_OPTIMIZE_FOR_SIZE enabled, appear
> below. Pardon the bad methodology.
>
> $ size vmlinux.*
> text data bss dec hex filename
> 2333474 461848 479920 3275242 31f9ea vmlinux.344.inline
> 2327319 462000 479920 3269239 31e277 vmlinux.344.noinline
> 2319085 461608 479984 3260677 31c105 vmlinux.402.inline
> 2313578 461800 479984 3255362 31ac42 vmlinux.402.noinline
Here are the results for gcc 3.4.4 and 4.0.2, built _without_
-Os:
$ size vmlinux*noopt
text data bss dec hex filename
2584202 461848 479920 3525970 35cd52 vmlinux.344.inline.noopt
2578246 462000 479920 3520166 35b6a6 vmlinux.344.noinline.noopt
2626475 461856 479984 3568315 3672bb vmlinux.402.inline.noopt
2620807 462016 479984 3562807 365d37 vmlinux.402.noinline.noopt
Kurt
--
There are really not many jobs that actually require a penis or a
vagina, and all other occupations should be open to everyone.
-- Gloria Steinem
Kurt Wall wrote:
> Right, I need to isolate the effects of each variable. Results for gcc
> 3.4.4 and 4.0.2, built with CONFIG_CC_OPTIMIZE_FOR_SIZE enabled, appear
> below. Pardon the bad methodology.
>
> $ size vmlinux.*
> text data bss dec hex filename
> 2333474 461848 479920 3275242 31f9ea vmlinux.344.inline
> 2327319 462000 479920 3269239 31e277 vmlinux.344.noinline
> 2319085 461608 479984 3260677 31c105 vmlinux.402.inline
> 2313578 461800 479984 3255362 31ac42 vmlinux.402.noinline
Yes, thats more like the rest of the results I seen... BTW, what is the .config?
Here are my results. Kernel is 2.6.15-rc7, gcc is 4.0.2 (Gentoo 4.0.2-r2,
HTB-4.0.2-1.00, pie-8.7.8)
'ay' denotes allyesconfig, def is defconfig.
I believe that neither of these have OPTIMIZE_FOR_SIZE turned on, but I didn't
play with that.
allyesconfig made a huge kernel, so I manually 'fixed' the formatting.
kaitou inlinetest # size *def*
text data bss dec hex filename
3676326 1084576 584920 5345822 51921e vmlinux.def.inline
3658652 1085168 584920 5328740 514f64 vmlinux.def.noinline
kaitou inlinetest # size *ay*
text data bss dec hex filename
22911557 7523774 1997000 32432331 1eee0cb vmlinux.ay.inline
22783415 7525934 1997000 32306349 1ecf4ad vmlinux.ay.noinline
defconfig:
17674 byte difference (0.4%) in text.
allyesconfig:
128142 byte difference (0.6%) in text.
Unless my math is off, that is.
--
[Name ] :: [Matan I. Peled ]
[Location ] :: [Israel ]
[Public Key] :: [0xD6F42CA5 ]
[Keyserver ] :: [keyserver.kjsl.com]
encrypted/signed plain text preferred
Matan Peled wrote:
> Here are my results. Kernel is 2.6.15-rc7, gcc is 4.0.2 (Gentoo
> 4.0.2-r2, HTB-4.0.2-1.00, pie-8.7.8)
Forgot to mention, these are amd64 kernels,,,
--
[Name ] :: [Matan I. Peled ]
[Location ] :: [Israel ]
[Public Key] :: [0xD6F42CA5 ]
[Keyserver ] :: [keyserver.kjsl.com]
encrypted/signed plain text preferred
Hi,
>> the "noinline" cases were built with Arjan's patch and
>> CONFIG_CC_OPTIMIZE_FOR_SIZE; the "inline" kernels were built,
>> obviously, without the patch and without CONFIG_CC_OPTIMIZE_FOR_SIZE.
>
> Wait, so how do we know if its GCC's -Os that caused the reduction in .text
> size, or the noinline patch ... ?
>
> To get actual results, you should either take OPTIMIZE_FOR_SIZE out the
> equation or use it on the other kernel as well...
I tried various kernel compilations; for fun and joy, I built a totally
monolithic kernel with almost all options turned on. I probably won't
boot it, heh. First, there were some modules/sourcefiles that fail to
compile:
CONFIG_MTD_AMDSTD
CONFIG_MTD_JEDEC
CONFIG_FB_PM3
There are also some issues in drivers/net/wan/sdla_*.c that I had to
fix before make was able to link to .tmp_vmlinux1.bin. I will post a
compile-fix in another thread. Now back to the inlining part. I have a
number of flavors to show...
All done with gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)
std: vanilla 2.6.15-rc7
Os: vanilla + CONFIG_OPTIMIZE_FOR_SIZE
noinl: vanilla + Arjan's noinline
noinl-Os: vanilla + CONFIG_OPTIMIZE_FOR_SIZE + noinline
Specials:
NFI: no forced inline (removal of always_inline part)
Information from make (bzImage):
std: System is 12226 kB
Os: System is 10879 kB
noinl: System is 12181 kB
noinl-Os: System is 10851 kB
NFI: System is 12198 kB
ls -l:
-rwxr-xr-x 26999081 Jan 2 17:43 rc7-noinl-Os/vmlinux
-rwxr-xr-x 27115266 Jan 2 15:48 rc7-Os/vmlinux
-rwxr-xr-x 30010293 Jan 2 17:24 rc7-noinl/vmlinux
-rwxr-xr-x 30058462 Jan 2 19:37 rc7-NFI/vmlinux
-rwxr-xr-x 30150993 Jan 2 15:45 rc7-std/vmlinux
size:
text data bss dec hex filename
17188479 5984442 1738248 24911169 17c1d41 rc7-noinl-Os/vmlinux
17313751 5980978 1738248 25032977 17df911 rc7-Os/vmlinux
20174873 5991726 1738248 27904847 1a9cb4f rc7-noinl/vmlinux
20222221 5992278 1738248 27952747 1aa866b rc7-NFI/vmlinux
20321527 5988706 1738248 28048481 1abfc61 rc7-std/vmlinux
Jan Engelhardt
--
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/
Jan Engelhardt wrote:
> Hi,
> size:
> text data bss dec hex filename
> 17188479 5984442 1738248 24911169 17c1d41 rc7-noinl-Os/vmlinux
> 17313751 5980978 1738248 25032977 17df911 rc7-Os/vmlinux
> 20174873 5991726 1738248 27904847 1a9cb4f rc7-noinl/vmlinux
> 20222221 5992278 1738248 27952747 1aa866b rc7-NFI/vmlinux
> 20321527 5988706 1738248 28048481 1abfc61 rc7-std/vmlinux
>
>
> Jan Engelhardt
Just out of pure curiosity... Where would NFI-Os stand?
one would expect it to be around 17225???...
--
[Name ] :: [Matan I. Peled ]
[Location ] :: [Israel ]
[Public Key] :: [0xD6F42CA5 ]
[Keyserver ] :: [keyserver.kjsl.com]
encrypted/signed plain text preferred
On Mon, Jan 02, 2006 at 07:51:15PM +0100, Jan Engelhardt wrote:
> Hi,
Hi Jan,
> I tried various kernel compilations; for fun and joy, I built a totally
> monolithic kernel with almost all options turned on. I probably won't
> boot it, heh. First, there were some modules/sourcefiles that fail to
> compile:
>
> CONFIG_MTD_AMDSTD
> CONFIG_MTD_JEDEC
> CONFIG_FB_PM3
>
> There are also some issues in drivers/net/wan/sdla_*.c that I had to
> fix before make was able to link to .tmp_vmlinux1.bin. I will post a
> compile-fix in another thread. Now back to the inlining part. I have a
> number of flavors to show...
>...
Don't set CONFIG_CLEAN_COMPILE=n ...
> Jan Engelhardt
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
On Mon, Jan 02, 2006 at 06:24:31PM +0200, Matan Peled took 0 lines to write:
> Kurt Wall wrote:
> >Right, I need to isolate the effects of each variable. Results for gcc
> >3.4.4 and 4.0.2, built with CONFIG_CC_OPTIMIZE_FOR_SIZE enabled, appear
> >below. Pardon the bad methodology.
> >
> >$ size vmlinux.*
> > text data bss dec hex filename
> >2333474 461848 479920 3275242 31f9ea vmlinux.344.inline
> >2327319 462000 479920 3269239 31e277 vmlinux.344.noinline
> >2319085 461608 479984 3260677 31c105 vmlinux.402.inline
> >2313578 461800 479984 3255362 31ac42 vmlinux.402.noinline
>
> Yes, thats more like the rest of the results I seen... BTW, what is the
> .config?
The .config is relatively plain vanilla, but customized for my own
desktop system, naturally. Mostly modular save for boot filesystems
and a few other odds and ends. Available as
http://www.kurtwerks.com/linux/config-2.6.15-rc6.
> allyesconfig made a huge kernel, so I manually 'fixed' the formatting.
I'll say. I tried it here -- it took a long time to link a 20MB file.
Kurt
--
Is it possible that software is not like anything else, that it is
meant to be discarded: that the whole point is to always see it as a
soap bubble?
>> size:
>> text data bss dec hex filename
>> 17188479 5984442 1738248 24911169 17c1d41 rc7-noinl-Os/vmlinux
>> 17313751 5980978 1738248 25032977 17df911 rc7-Os/vmlinux
>> 20174873 5991726 1738248 27904847 1a9cb4f rc7-noinl/vmlinux
>> 20222221 5992278 1738248 27952747 1aa866b rc7-NFI/vmlinux
>> 20321527 5988706 1738248 28048481 1abfc61 rc7-std/vmlinux
>
> Just out of pure curiosity... Where would NFI-Os stand?
>
> one would expect it to be around 17225???...
LD .tmp_vmlinux1
arch/i386/kernel/built-in.o: In function `fix_to_virt':
: undefined reference to `__this_fixmap_does_not_exist'
arch/i386/kernel/built-in.o: In function `fix_to_virt':
: undefined reference to `__this_fixmap_does_not_exist'
arch/i386/kernel/built-in.o: In function `fix_to_virt':
: undefined reference to `__this_fixmap_does_not_exist'
arch/i386/kernel/built-in.o: In function `fix_to_virt':
: undefined reference to `__this_fixmap_does_not_exist'
arch/i386/kernel/built-in.o: In function `fix_to_virt':
: undefined reference to `__this_fixmap_does_not_exist'
arch/i386/kernel/built-in.o:: more undefined references to
`__this_fixmap_does_not_exist' follow
make: *** [.tmp_vmlinux1] Error 1
I hacked it up a little to get a result so...
text data bss dec hex filename
17286376 4281178 1738248 23305802 1639e4a .tmp_vmlinux1
Jan Engelhardt
--