Announcement

Collapse
No announcement yet.

LTO Support Coming To Linux 3.15, Making For A Faster Kernel

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

  • LTO Support Coming To Linux 3.15, Making For A Faster Kernel

    Phoronix: LTO Support Coming To Linux 3.15, Making For A Faster Kernel

    As a potentially significant performance win for the Linux kernel, when compiling the Linux kernel support for link-time optimizations (LTO) are now supported...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    ...it was found the resulting Linux kernel image was faster in various benchmarks.
    How much faster? Like 1 to 3%? Or more serious improvements that can actually be noticed by the user.

    Comment


    • #3
      Originally posted by mark45 View Post
      How much faster? Like 1 to 3%? Or more serious improvements that can actually be noticed by the user.
      if you go and disable useless thing and/or debug things from the kernel and compile your own ,i saw unigine valley go from 600 point to 800 points, by just optimizing the kernel .config . i would very much like to see a phoronix test about this, i used the pts to make a few standard vs custom kernel speed and i consistently saw a 20% speed improvement across the board.

      Comment


      • #4
        Originally posted by mark45 View Post
        How much faster? Like 1 to 3%? Or more serious improvements that can actually be noticed by the user.
        Disregarding the average user, even a 1-3% increase in performance can spell wonders for places like super-computing and Android Phones. I bet it's more than that too, like sireangelus said: 600-800 is a 33% improvement, and it's an ~20% increase across the board.

        Comment


        • #5
          If the performance improvements gets over 10% for LTO, it usually means that developers could look into that and restructure headers/source files so optimizer can do the trick w/o LTO, too. In well tuned code, like Kernel is, I would not expect that many places like this. Important benefit however is the code size decrease that usually quite substantial (over 30%) and not easily reachable by few source code reorgs.

          Also note that modules makes many symbols used externally, so best improvements you will see on monolithic kernels with modules disabled. I would guess this to be useful for small devices.

          Comment


          • #6
            Originally posted by hubicka View Post
            If the performance improvements gets over 10% for LTO, it usually means that developers could look into that and restructure headers/source files so optimizer can do the trick w/o LTO, too. In well tuned code, like Kernel is, I would not expect that many places like this. Important benefit however is the code size decrease that usually quite substantial (over 30%) and not easily reachable by few source code reorgs.

            Also note that modules makes many symbols used externally, so best improvements you will see on monolithic kernels with modules disabled. I would guess this to be useful for small devices.
            When I ran Gentoo on my laptop in 2008 I ran with a custom monolithic kernel. I used one of those scripts to detect your hardware and set the kernel config to start with, then I customized it from there. I turned on most of the USB drivers for example so that things would work when I plugged them in. I turned off almost all the legacy support options and gave it a built in custom initramfs with busybox.

            So it is useful for more than small systems. It works well on laptops and desktops too.

            Comment


            • #7
              Originally posted by hubicka View Post
              so best improvements you will see on monolithic kernels with modules disabled.
              Does it really need modules to be disabled? Because I have all modules that I need compiled into the kernel except things I almost never use (like the FAT filesystem), external modules (VirtualBox) and buggy drivers (the AMD microcode driver seems to work when compiled as a module only, for example).

              Comment


              • #8
                Originally posted by TAXI View Post
                Does it really need modules to be disabled? Because I have all modules that I need compiled into the kernel except things I almost never use (like the FAT filesystem), external modules (VirtualBox) and buggy drivers (the AMD microcode driver seems to work when compiled as a module only, for example).
                Enabling modules will prevent compiler to propagate known values into functions that may be used by the module. Since these are annotated, it may not be disasterous. I can't easily google any bechmarks on that...

                Comment


                • #9
                  Does anyone know of a simple way to measure memory usage when compiling a kernel?

                  I have a small, no module, all-in-one kernel. LTO might be feasable since I have at least 1,5 gig of memory. Could a 4,5 mb linux image need 1,5 gig for LTO? This made me realize it used to be only 2,2MB on that same machine once upon a time .

                  I do think that the cost benefit tradeoff is a negative one.

                  Comment


                  • #10
                    Originally posted by Rexilion View Post
                    I do think that the cost benefit tradeoff is a negative one.
                    It might be for individual users compiling their own kernels, but since distros compile tons of stuff already the cost to them is negligible. And I bet the vast majority of Linux users are using distro-compiled kernels.

                    Comment

                    Working...
                    X