Looking At Building The Linux Kernel With -O3 Optimizations

[phoronix]

Phoronix: Looking At Building The Linux Kernel With -O3 Optimizations

A Linux user has started an LKML discussion over compiling the kernel with -O3 for driving performance improvements out of a more-optimized kernel binary...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-O3-Optimizations

[halo9en]

This optimization gives a nice boost https://github.com/graysky2/kernel_gcc_patch

[FireBurn]

This optimization gives a nice boost https://github.com/graysky2/kernel_gcc_patch

I've been using that patch for a while, I remember many years ago using O3 in the kernel but it did cause me a few issues with not enough gains to justify it

I'd be curious to see some benchmarks with O2 Os O3 and Ofast (Os has a flag somewhere under embedded)

[gens]

(Os has a flag somewhere under embedded)

it's "Optimize for size" and it's under... "General setup"

[stqn]

This optimization gives a nice boost https://github.com/graysky2/kernel_gcc_patch

A nice boost? Maybe I don?t understand the results, but to me they look like a 0.05% improvement??

[birdie]

Using -O3 for building the kernel is way too risky, because even at -O2 GCC sometimes makes serious errors resulting in an unstable kernel.

Even without these errors -O3 will benefit very few users since in most daily tasks the kernel consumes the negligible amount of CPU time.

[alpha_one_x86]

Processor type and features -> Processor family?
+1 to test https://github.com/graysky2/kernel_gcc_patch

Same out of kernel code, personaly I compil all my user space with -march=native -mtune=native -mcpu=native

[alpha_one_x86]

-march=native satisfies, no need for the rest.

Maybe, I have just take a look to:

gcc -march=native -Q --help=target

And:

gcc -march=native -mtune=native -mcpu=native -Q --help=target

[Guest]

Using -O3 for building the kernel is way too risky, because even at -O2 GCC sometimes makes serious errors resulting in an unstable kernel.

Even without these errors -O3 will benefit very few users since in most daily tasks the kernel consumes the negligible amount of CPU time.

Not sure if risky, but surely untested.
I asked at kernelniewbies@oftc some years ago and I was told that stuff like --march=native indiscriminatedly add sse optimizations which can in turn make context switches more costly (along with 15-25% bigger code size).
There likely are use cases where -O3 -march=native can be beneficial, but enabling it by default isn't going to hapen with all likelyhood, it could possibly double the testing effort required and obfuscate quite a few bugs.
Probably not worth that 5% performance improvement in very specific cases (same goes for all software compiled with -O3, probably not worth the trouble).

I think better solution would be using -mtune=native option, It carries no aditional risk that I'm aware of and it can optimize things a bit for target cpu (mostly due to better cache & pipeline decisions that compiler can make).

What I would be interested in tho would be some gaming benchmarks to see improvement as games provide nice mixture of asyncIO/multithreading/contextswitches/gpuoffloading.

[ext73]

It's still not too much You can be more - see my kernels, especially from Premium series:

www.netext73.pl

for example:

PTS results

Regards