Announcement

Collapse
No announcement yet.

Torvalds Is Unconvinced By LTO'ing A Linux Kernel

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

  • 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

  • #2
    This is a cool article

    I hope it works on sparc32 despite being a less used architecture and sparc64 as well I'll be updating my kernel there soon as SMP support has been fixed (previously SMP kernels locked up on many UltraSparc boxes unless you forced them into uniprocessor mode)

    Smaller kernels are really important for sparc32 as the kernel is at the point where you can't compile many drivers into the 3.4MB or so limit. Its around that anyway.. I think newer versions of SILO might have lifted that somewhat but I am not sure.

    Smaller faster kernel why would ANYONE complain?
    Last edited by cb88; 04-09-2014, 03:35 AM.

    Comment


    • #3
      Originally posted by cb88 View Post
      This is a cool article

      I hope it works on sparc32 despite being a less used architecture and sparc64 as well I'll be updating my kernel there soon as SMP support has been fixed (previously SMP kernels locked up on many UltraSparc boxes unless you forced them into uniprocessor mode)

      Smaller kernels are really important for sparc32 as the kernel is at the point where you can't compile many drivers into the 3.4MB or so limit. Its around that anyway.. I think newer versions of SILO might have lifted that somewhat but I am not sure.

      Smaller faster kernel why would ANYONE complain?
      Another good use case is embedded. Routers and small devices might have 2 to 64 MB of flash. Even with XZ compression modern Linux can be 3 MB on x86 with almost every feature disabled. Too bad Linus is such a douche and doesn't care about fighting bloat.

      Comment


      • #4
        Originally posted by caligula View Post
        Another good use case is embedded. Routers and small devices might have 2 to 64 MB of flash. Even with XZ compression modern Linux can be 3 MB on x86 with almost every feature disabled. Too bad Linus is such a douche and doesn't care about fighting bloat.
        Yeh, we don't care that the maintainers don't even call for testing and crap... give us that unstable shit! Don't even test any of the patches on the kernel! No wait... its not even necessary to have an succesfull build of the kernel, ill just watch the code

        Comment


        • #5
          sounds like we're going to see a ten page article full of benchmark graphs some time soon

          Comment


          • #6
            Originally posted by caligula View Post
            Another good use case is embedded. Routers and small devices might have 2 to 64 MB of flash. Even with XZ compression modern Linux can be 3 MB on x86 with almost every feature disabled. Too bad Linus is such a douche and doesn't care about fighting bloat.
            thing is the code itself does not bring much to the footprint of a running kernel

            Comment


            • #7
              So someone has to make tests and benchamarks to evaluate its capabilities, problems and advantages.

              Comment


              • #8
                Originally posted by gens View Post
                thing is the code itself does not bring much to the footprint of a running kernel
                Flash space, not the runtime footprint, is usually the problem in routers (which usually carry more RAM than Flash).

                Comment


                • #9
                  I'm not sure I would want that thing in kernel just yet.

                  kernel is a thin layer of code anyway. There is not much potential for sizeable speed gains there, even if LTO would work much better than it does.

                  I've toyed with it and have seen many weird errors, so I recompiled everything with bog standard "-march=native -O2"

                  LTO is interesting as an idea, but with this gcc and binutils... no, thanks. I'll wait for next round of gcc before I try again.

                  And this goes even more for kernel. Having schisophrenic userland is bad enough, but stuffing that into kernel intself could be a disaster.

                  Comment


                  • #10
                    WTF

                    WTF is "Unconvined"? Is it Unconvinced because seriously spellcheck?

                    Comment

                    Working...
                    X