Torvalds Is Unconvinced By LTO'ing A Linux Kernel

[curaga]

BTW, I have noticed on Jan Hubicka's blog that LTO brings most benefits when used with aggressive optimisations like -O3 and profiling driven optimisation.

So it would be nice to have that option with kernel, too. If it wouldn't break anything.

How would you PGO the kernel so that it doesn't become slow for some case you didn't test?

[Brane215]

BTW, I have noticed on Jan Hubicka's blog that LTO brings most benefits when used with aggressive optimisations like -O3 and profiling driven optimisation.

So it would be nice to have that option with kernel, too. If it wouldn't break anything.

[MWisBest]

LTO option sounds nice for release kernels of distributions (because generally you don't wanna wait hours for kernel to build while consuming a _lot_ of ram).
I tried building my custom kernel with LTO and it ate 3GB of ram (and my kernel is fairly slim - stripped of unneeded modules).
I dont think my 8gb of ram would suffice for allconfig, though patches seem to have mitigated ram usege to some extent (firefox LTO build takes 7gigs easily on 64bit).

With building Android with LTO, I've noticed that it'll just use as much RAM as it can, with more RAM available it takes less time but it doesn't seem to fail or anything when there is less RAM available. This leads me to believe that available RAM with LTO isn't really a problem, at least when you get past 4GB or so.

LTO option sounds nice for release kernels of distributions (because generally you don't wanna wait hours for kernel to build while consuming a _lot_ of ram).
I tried building my custom kernel with LTO and it ate 3GB of ram (and my kernel is fairly slim - stripped of unneeded modules).
I dont think my 8gb of ram would suffice for allconfig, though patches seem to have mitigated ram usege to some extent (firefox LTO build takes 7gigs easily on 64bit).

[hubicka]

The promised numbers on LTO and FIrefox http://hubicka.blogspot.ca/2014/04/l...2-firefox.html

[MWisBest]

And WEEKS of lost time, mopping the cr*p afteer each such gain have lost me half of lifetime already. And it is adding up infinitely faster.
Doing it for testing is fine, but using this in kernel for 1% gain on some irellevant test for 99.999% of the planet while risking for the thing to ge berserk and make fruit salad out of one's disk/s/ is IMHO moronic.

Nobody said LTO is going to be FORCED in the kernel. It would probably be quite the opposite.

[ryao]

Have you noticed that even now even here no one actually knows even loosely WTF this is and how it is supposed to work ?

Speak for yourself.

[gens]

yes, floating point is banned from the kernel for a couple reason
one being just that, that its behavior is dependent on some flags (and they are cpu wide)

check out http://softpixel.com/~cwright/programming/simd/sse.php , the mxcsr register is for sse (x87 has even more stuff)

can't edit
http://wiki.osdev.org/SSE better explains what needs to be done
also i'm not 100% about how userspace floating point is handled, never had problems with it (tbh never needed to change the state, so..)

[gens]

It turns out this is not strictly correct. Older Linux kernels use the ts bit on x86 to try to avoid reloads as much as possible:

http://stackoverflow.com/a/431323

It is still basically what I described earlier though. The kernel simply does not need floating point arithmetic. Sometimes, vector instructions are useful, but in those times, we use critical sections. Anyway, few kernel developers ever use these functions.

yes, floating point is banned from the kernel for a couple reason
one being just that, that its behavior is dependent on some flags (and they are cpu wide)

check out http://softpixel.com/~cwright/programming/simd/sse.php , the mxcsr register is for sse (x87 has even more stuff)

[caligula]

FTFY.
One can care about linux and still not care about what you specifically care.

I use Linux because it's great for servers, embedded and development desktops, but most games only work on Windows and Macs are great when travelling since their power consumption is low (only on Mac OS X), great UI/UX, great looks, good quality, nice.