# [POLLING] -Os for kernel is good or not? :)

## Bash[DevNull]

Interesting in yours opinion

----------

## bollucks

Yes

(If you can find a workload, any workload with hard numbers to show it's better or worse I'll be very very impressed)

----------

## frenkel

No, get's loaded once and after that stays in memory. It's _the_ most important thing your computer is running, don't optimize for size, but for speed.

----------

## tkdfighter

If you want to run the Linux kernel on an embedded system, you should probably optimize for size using -Os. But for any other computer you will want to go for -O2.

But that's just my 2c.

----------

## bollucks

Here read an informed decision:

http://article.gmane.org/gmane.linux.kernel.ck/4689

----------

## stef

Well, I am using -Os for my kernel now

(have been using -Os as CFLAG for my system some time and well ... had more ram which for me felt speeding up things as less swapping makes everything way faster) ... 

I recently changed back my CFLAGS to -O2 since -Os caused some bad binaries for some kde packages (gcc is a hard thing to keep working correctly)

 but so far kernel seems to be running perfectly so i keep this... (and maybe also try -Os for CFLAGS again and see if gcc does it now)

----------

## Bash[DevNull]

 *stef wrote:*   

> Well, I am using -Os for my kernel now
> 
> (have been using -Os as CFLAG for my system some time and well ... had more ram which for me felt speeding up things as less swapping makes everything way faster) ... 
> 
> I recently changed back my CFLAGS to -O2 since -Os caused some bad binaries for some kde packages (gcc is a hard thing to keep working correctly)
> ...

 

and how much RAM in your system?

On my NoteBook just 256Mb... so im thinking to change -O3 to -Os for all packages...

----------

## stef

I have 512 MB on AMD64 (so progs get a little bigger because of pointers being 64 instead of 32 bit)

But well .. yesterday i got IO error on my hd, so I guess it maybe still buggy gcc for me on -Os .. so i'll switch back to normal compilation for kernel and see if it's bad hardware or really a software/compiler problem)

----------

## Kaapeli

 *bollucks wrote:*   

> Here read an informed decision:
> 
> http://article.gmane.org/gmane.linux.kernel.ck/4689

 

(quoted from the above website)

 *Quote:*   

> 
> 
> Well the kernel is a different beast to userspace. The cycles saved by using 
> 
> O2 in the kernel are almost certainly offset by the extra icache footprint of 
> ...

 

My thought is that saving a few megabytes doesn't really have any significant speedup on userspace, especially if you already have a gigabyte of ram or so. I understand that if you're very low in ram, saving a few megabytes can make a difference, but PCs today tend to have so much ram that saving a few megabytes will only have very marginal effect on userspace performance.

 *Quote:*   

> It is not common that a kernel 
> 
> function itself actually costs you much in cpu cycles, so this is a better 
> 
> compromise - most of your cycles are spent in userspace. If the kernel _is_ 
> ...

 

I thought that the sys column on top and vmstat indicates the amount of CPU cycles spent on kernel mode. When running some scripts that forks a lot (emerging something for example), it's not uncommon for me to see the sys percentage to go above 50% level. Does that mean my CPU is spending way too much time in kernel mode or something else?

----------

## bollucks

 *Kaapeli wrote:*   

> My thought is that saving a few megabytes doesn't really have any significant speedup on userspace, especially if you already have a gigabyte of ram or so. I understand that if you're very low in ram, saving a few megabytes can make a difference, but PCs today tend to have so much ram that saving a few megabytes will only have very marginal effect on userspace performance.

 

The L1 cache in your cpu is absolutely miniscule. This isn't about ordinary ram. Check the output of the command:

```
dmesg | grep L1
```

 and you'll see why it counts. This is the fastest ram your CPU operates from, followed by the L2 cache (substitute L1 above with L2). This does matter.

 *Kaapeli wrote:*   

> I thought that the sys column on top and vmstat indicates the amount of CPU cycles spent on kernel mode. When running some scripts that forks a lot (emerging something for example), it's not uncommon for me to see the sys percentage to go above 50% level. Does that mean my CPU is spending way too much time in kernel mode or something else?

 

That's usually for short bursts when you are calling on system resources and are limited in ways beyond simple CPU "calculations". Most things spend their time in userspace, and if they don't there's something wrong. Real cpu bound things like mp3 encoding and the like use close to zero system time except when waiting on I/O.

As I said originally, though: If you can find any hard evidence it helps either way I'll be impressed.

----------

## stef

just for information:

switched back to kernel without -Os after the IO error mentioned above.

s.m.a.r.t. does not find any errors and I didn't get any IO errors anymore,

so seems to be a bug in gcc (GCC) 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8 )

on amd64 .. at least for me. (hopefully they'll get -Os fixed in gcc some days)

just in case one didn't think of L1/L2 caches and is too lazy to look it up - here' mine:

CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)

CPU: L2 Cache: 512K (64 bytes/line)

so really some MB more or less do make a difference.

----------

## stef

switched to gcc 4.1 ... and now trying -Os kernel 2.6.16-r1 - up to now everything fine!

----------

## sirdilznik

I've been running -Os for my kernel since it became an option (rest of my system is -O2).  As far as stability goes I've had zero issues.  As far as performance goes, I agree with bollucks, performance difference is negligible if any.

----------

