# The new "Optimize for size" kernel option in gentoo-sources

## GetCool

In gentoo-sources 2.6.15-r1 (on AMD64, at least)...

```
General setup --->

  [*] Optimize for size (Look out for broken compilers!)

------------------------

CONFIG_CC_OPTIMIZE_FOR_SIZE:

Enabling this option will pass "-Os" instead of "-O2" to gcc resulting in a smaller kernel.

WARNING: some versions of gcc may generate incorrect code with this option.  If problems are observed, a gcc upgrade may be needed.
```

I'm just wondering how this really affects the kernel, and why it is selected by default in 2.6.15.  It doesn't seem like an option meant for general use.

Personally, I disabled it, but I'm just curious...

----------

## anonybosh

From the g++ manual doc: *Quote:*   

> -Os Optimize for size.  -Os enables all -O2 optimizations that do not typically increase code size.  It also performs further optimizations designed to reduce code size.
> 
> -Os disables the following optimization flags: -falign-functions  -falign-jumps  -falign-loops  -falign-labels  -freorder-blocks  -fprefetch-loop-arrays
> 
> ...
> ...

 

I would guess it probably doesn't make too much of difference in performance, and maybe reduces size a little. What's not to like?

----------

## RoundsToZero

The part about incorrect code generation  :Very Happy: .

----------

## anonybosh

Maybe older gcc compilers don't recognize to -0s flag...thusly "a gcc upgrade may be needed."?

----------

## GetCool

 *RoundsToZero wrote:*   

> The part about incorrect code generation .

 

Indeed.

Although I'm sure current versions of gcc won't have a problem... I was just surprised to see it as a default option.  But then again, one of the 10Gb network adapter drivers is enabled as a module by default   :Rolling Eyes: 

----------

## bollucks

Many distributions have been using this by default on their kernels already. A huge discussion on lkml described the advantages of a smaller kernel. In a nutshell if you spend .1% of your cpu time in the kernel then speeding that up with -O2 has immeasurable benefit and there is more to be gained by leaving more ram free for userspace to use. The warning about incorrect code is a theoretical one and any gcc >=3.2 will be fine.

----------

## GetCool

 *bollucks wrote:*   

> In a nutshell if you spend .1% of your cpu time in the kernel then speeding that up with -O2 has immeasurable benefit and there is more to be gained by leaving more ram free for userspace to use.

 

And the gain you'll get from freeing up that extra fraction of a megabyte of RAM is measurable?

With kernels only a few MB in size, and RAM quantities commonly 1 GB or greater, I fail to see how making the -Os optomization a default option is a step forward.

----------

## RuiP

I didn't realize that this option was on by default. 

Now i understand why it has size of 1767164 and the the previous 2.6.14-r5 a size of 1970561 (10% smaller), with exactly the same options!

My all system is compiled with -Os, and everything compiles and works without a problem.

----------

## heise2k

 *GetCool wrote:*   

>  *bollucks wrote:*   In a nutshell if you spend .1% of your cpu time in the kernel then speeding that up with -O2 has immeasurable benefit and there is more to be gained by leaving more ram free for userspace to use. 
> 
> And the gain you'll get from freeing up that extra fraction of a megabyte of RAM is measurable?
> 
> With kernels only a few MB in size, and RAM quantities commonly 1 GB or greater, I fail to see how making the -Os optomization a default option is a step forward.

 

With the kernel it's not the RAM so much as the icache savings that -Os will provide. See what Linus had to say on this:

http://marc.theaimsgroup.com/?l=linux-kernel&m=104457390406050&w=2

Tchüss!

heise2k

----------

