Announcement

Collapse
No announcement yet.

Torvalds Is Unconvinced By LTO'ing A Linux Kernel

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic Torvalds Is Unconvinced By LTO'ing A Linux Kernel

    Torvalds Is Unconvinced By LTO'ing A Linux Kernel

    Phoronix: Torvalds Is Unconvined By LTO'ing A Linux Kernel

    Yesterday patches were published via a pull request to enable experimental LTO support for the Linux 3.15 kernel, but Linus Torvalds hasn't yet decided whether he will accept this code in the upstream Linux kernel... Linus doesn't yet see the benefits in link-time optimizations for the kernel and isn't sure whether this code is ready yet to be mainlined...

    http://www.phoronix.com/vr.php?view=MTY1OTg

  • curaga
    replied
    Originally posted by Brane215 View Post
    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?

    Leave a comment:


  • Brane215
    replied
    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.

    Leave a comment:


  • MWisBest
    replied
    Originally posted by tpruzina View Post
    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.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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).

    Leave a comment:


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

    Leave a comment:


  • MWisBest
    replied
    Originally posted by Brane215 View Post
    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.

    Leave a comment:


  • ryao
    replied
    Originally posted by Brane215 View Post
    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.

    Leave a comment:


  • gens
    replied
    Originally posted by gens View Post
    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..)

    Leave a comment:


  • gens
    replied
    Originally posted by ryao View Post
    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)

    Leave a comment:

Working...
X