Page 1 of 8 123 ... LastLast
Results 1 to 10 of 75

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

  1. #1
    Join Date
    Jan 2007
    Posts
    13,474

    Default 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. #2
    Join Date
    Nov 2008
    Posts
    418

    Default

    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.

  3. #3
    Join Date
    Apr 2008
    Posts
    325

    Default

    Quote 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.

  4. #4
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,532

    Default

    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.

  5. #5
    Join Date
    Nov 2010
    Posts
    58

    Default

    Quote 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.

  6. #6
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,532

    Default

    Quote 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.

  7. #7
    Join Date
    Nov 2010
    Posts
    58

    Default

    Quote 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?

  8. #8
    Join Date
    Jul 2009
    Posts
    221

    Default

    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?

  9. #9

    Default

    Quote 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.

  10. #10
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,532

    Default

    Quote 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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •