Announcement

Collapse
No announcement yet.

Five Years Of Linux Kernel Benchmarks: 2.6.12 Through 2.6.37

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

  • Five Years Of Linux Kernel Benchmarks: 2.6.12 Through 2.6.37

    Phoronix: Five Years Of Linux Kernel Benchmarks: 2.6.12 Through 2.6.37

    While we have conducted studies related to the Linux kernel performance in the past such as benchmarking up to twelve kernel releases, going out the door this morning are the results from the largest-ever Linux kernel comparison conducted at Phoronix, and very likely the largest ever of its kind regardless of source. Every major Linux kernel release from Linux 2.6.12, which was released in mid-2005, up through the latest Linux 2.6.37 development code was tested. This represents the past five years of the Linux kernel and shows how the performance has evolved over the past 25 stable kernel releases and the most recent 2.6.37 development kernel.

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

  • #2
    Interesting that also, Intel corp, has confirmed that Linux is getting slower and slower. Maybe this is because Linux is getting more and more bloated?

    http://www.theregister.co.uk/2009/09..._bloated_huge/
    "Citing an internal Intel study that tracked kernel releases, Bottomley said Linux performance had dropped about two per centage points at every release, for a cumulative drop of about 12 per cent over the last ten releases. "Is this a problem?" he asked.

    "We're getting bloated and huge. Yes, it's a problem," said Linux Torvalds."



    Maybe Linux should focus one release on bug fixes instead of introducing new functionality all the time? Just like Apple did. One of the recent big Mac OX S releases was devoted to only bug fixes and slimming down OS X. Which paid off.

    Comment


    • #3
      Originally posted by kebabbert View Post
      Interesting that also, Intel corp, has confirmed that Linux is getting slower and slower. Maybe this is because Linux is getting more and more bloated?

      http://www.theregister.co.uk/2009/09..._bloated_huge/
      "Citing an internal Intel study that tracked kernel releases, Bottomley said Linux performance had dropped about two per centage points at every release, for a cumulative drop of about 12 per cent over the last ten releases. "Is this a problem?" he asked.

      "We're getting bloated and huge. Yes, it's a problem," said Linux Torvalds."



      Maybe Linux should focus one release on bug fixes instead of introducing new functionality all the time? Just like Apple did. One of the recent big Mac OX S releases was devoted to only bug fixes and slimming down OS X. Which paid off.
      I assume you are referring to Snow Leopard (10.6)... This was less a "bug fix and slim" release as it was a "recompile in 64bit" release.

      Comment


      • #4
        Well most of that "bloat" comes from added hardware support which unless you are forcing the modules to load that are not needed shouldn't add to the overhead. I would however love to see a Linux 2.8 kernel release where they trim down the hardware modules to reasonably recent hardware and get rid of the massive amounts of legacy hardware support that is still in the kernel.

        Comment


        • #5
          Originally posted by kebabbert View Post
          Maybe Linux should focus one release on bug fixes instead of introducing new functionality all the time?
          Developers are not interested in this, developers gets paid for features.

          If you want stable kernel, only bug fixes etc you can use RHEL or SLES kernel.

          Comment


          • #6
            Originally posted by RobbieAB View Post
            I assume you are referring to Snow Leopard (10.6)... This was less a "bug fix and slim" release as it was a "recompile in 64bit" release.
            That is over simplifying 10.6. 10.6 was more about trimming out legacy support (PPC) and features such as openCL.

            Comment


            • #7
              Originally posted by deanjo View Post
              I would however love to see a Linux 2.8 kernel release where they trim down the hardware modules to reasonably recent hardware and get rid of the massive amounts of legacy hardware support that is still in the kernel.
              I don't see any problem with drivers for an old hardware. Why do you want to remove them? Are these drivers broken or something?

              Comment


              • #8
                would there be a significant performance boost if kernel was compiled manually with only the drivers needed for a particular system?
                i had gentoo some time ago and i didnt see a huge performance increase.
                how come? i really had only the drivers i needed in there.
                does the BKL change of 2.6.37 affect single core systems like mine?

                Comment


                • #9
                  Originally posted by jakubo View Post
                  would there be a significant performance boost if kernel was compiled manually with only the drivers needed for a particular system?
                  i had gentoo some time ago and i didnt see a huge performance increase.
                  how come? i really had only the drivers i needed in there.
                  does the BKL change of 2.6.37 affect single core systems like mine?
                  The BKL removal shouldn't affect single-threaded systems at all because the BKL is used only for multi-threaded, multi-core, or multi-processing systems.

                  Comment


                  • #10
                    Originally posted by michal View Post
                    I don't see any problem with drivers for an old hardware. Why do you want to remove them? Are these drivers broken or something?
                    The resources that are required to maintain these products would be better put towards common hardware in use. It would also decrease compilation time, ease configuration options, reduce code complexity, and start bringing down the kernel to a reasonable size again on "in the can" distros. Lets face it, many distro's advertise minimum requirements that often exceed the capabilities of any hardware that would still have support for these products such as ISA solutions, micro-channel support, tolkien ring, etc.

                    Comment


                    • #11
                      Originally posted by deanjo View Post
                      The resources that are required to maintain these products would be better put towards common hardware in use.
                      No, an old drivers rarely needs updates.

                      Originally posted by deanjo View Post
                      It would also decrease compilation time,
                      You do not need to compile it. You can disable old drivers in config

                      Originally posted by deanjo View Post
                      ease configuration options,
                      not quite

                      Originally posted by deanjo View Post
                      reduce code complexity, and start bringing down the kernel to a reasonable size again on "in the can" distros.
                      it really does not matter

                      Originally posted by deanjo View Post
                      Lets face it, many distro's advertise minimum requirements that often exceed the capabilities of any hardware that would still have support for these products such as ISA solutions, micro-channel support, tolkien ring, etc.
                      AFAIR ISA code is still needed for PCI, PCI is still needed for PCIexpress.

                      I'm not sure if it's possible to remove isa even on x86_64. Zone DMA probably still has to be supported.

                      Comment


                      • #12
                        Originally posted by deanjo View Post
                        The resources that are required to maintain these products would be better put towards common hardware in use. It would also decrease compilation time, ease configuration options, reduce code complexity, and start bringing down the kernel to a reasonable size again on "in the can" distros. Lets face it, many distro's advertise minimum requirements that often exceed the capabilities of any hardware that would still have support for these products such as ISA solutions, micro-channel support, tolkien ring, etc.
                        BTW. The best would you do if asked about it at LKML - there, you'll get the most competent answers.

                        Comment


                        • #13
                          Originally posted by michal View Post
                          BTW. The best would you do if asked about it at LKML - there, you'll get the most competent answers.
                          Did long time ago and it was doable. Would have been easier however when x86 and x86-64 were still separate code bases.

                          Comment


                          • #14
                            Originally posted by michal View Post
                            No, an old drivers rarely needs updates.
                            Old drivers are quite often updated. One only needs to look at the alsa release logs there to see that.

                            You do not need to compile it. You can disable old drivers in config
                            Never said you couldn't however the trend for pre-compiled kernel configs is to modularize everything including the kitchen sink.

                            not quite
                            I really beg to differ, reducing the legacy hardware support would trim the config tree considerably.

                            it really does not matter
                            Sure it does, especially where installation / live media is concerned plus it would ease the burden on users that do not have a good high speed link.

                            AFAIR ISA code is still needed for PCI, PCI is still needed for PCIexpress.

                            I'm not sure if it's possible to remove isa even on x86_64. Zone DMA probably still has to be supported.
                            I'm talking more of ISA devices such as ISA video cards, ISA sound cards, ISA network cards, etc etc.

                            Comment


                            • #15
                              Originally posted by deanjo View Post
                              Did long time ago and it was doable. Would have been easier however when x86 and x86-64 were still separate code bases.
                              and would bring no real big benefits.

                              Comment

                              Working...
                              X