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

  • snadrus
    replied
    I'm very interested in seeing how the bisect is done. If you can trace all of those old regressions (and subtract out the ones already fixed later), then we should be able to reclaim nearly any performance point we were at before while keeping modern improvements.

    Leave a comment:


  • TemplarGR
    replied
    Actually, after having a quick look at the charts, i am actually pleased about kernel performance... It seems to me that after 5 years, it is almost the same(there are some exceptions of course). I believe this is is a good thing.

    There is another proprietary OS i know that needs more and more resources with every upgrade. Linux kernel on the other hand, needs almost the same, despite having added much more features in 5 years...

    Leave a comment:


  • deanjo
    replied
    Originally posted by michal View Post
    I realy don't see any benefit from removing code that I'm not using. {Removing dead, optimising} code etc. that is appreciated.



    Auditor?

    I doubt many people did the kernel code audit. Most of the work in this field is performed by automatic tools like Coverity Prevent, Coccinelle.
    When coding is done right it has to be done so that making a change does not cause issues with other code. Having to worry about that can complicate fixes and create unforeseen issues all for the sake of maintaining compatibility for items that only the rare few utilize. Often comprises are made for the sake of compatibility while sacrificing performance.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Originally posted by deanjo View Post
    Old drivers are quite often updated. One only needs to look at the alsa release logs there to see that.
    Yeah, but it's not a huge changes.

    Just take a look at
    git diff v2.6.36 --stat fs/ext4/
    fs/ext4/Makefile | 2 +-
    fs/ext4/balloc.c | 5 +-
    fs/ext4/block_validity.c | 7 +-
    fs/ext4/dir.c | 2 +-
    fs/ext4/ext4.h | 110 +++++++--
    fs/ext4/ext4_extents.h | 65 ++++-
    fs/ext4/extents.c | 368 ++++++++++++-----------------
    fs/ext4/file.c | 44 ++++-
    fs/ext4/fsync.c | 88 +++++++-
    fs/ext4/ialloc.c | 135 ++++++++++-
    fs/ext4/inode.c | 596 ++++++++++++++++------------------------------
    fs/ext4/mballoc.c | 557 ++++++++++++++++++++++++++++---------------
    fs/ext4/migrate.c | 2 +-
    fs/ext4/move_extent.c | 22 +-
    fs/ext4/namei.c | 65 +++---
    fs/ext4/page-io.c | 430 +++++++++++++++++++++++++++++++++
    fs/ext4/resize.c | 52 ++---
    fs/ext4/super.c | 566 ++++++++++++++++++++++++++++++++++++++++----
    fs/ext4/xattr.c | 4 +-
    fs/ext4/xattr.h | 10 +-
    20 files changed, 2147 insertions(+), 983 deletions(-)

    and compare this to

    git diff v2.6.36 --stat fs/ext2/
    fs/ext2/balloc.c | 3 +--
    fs/ext2/dir.c | 2 +-
    fs/ext2/ext2.h | 1 -
    fs/ext2/inode.c | 15 +++------------
    fs/ext2/namei.c | 2 +-
    fs/ext2/super.c | 18 +++++++++---------
    fs/ext2/xattr.c | 2 +-
    7 files changed, 16 insertions(+), 27 deletions(-)


    Maintaining old stuff is not _PITA_ for developers.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Originally posted by deanjo View Post
    Reducing code size and complexity always has it's benefits from a developer
    I realy don't see any benefit from removing code that I'm not using. {Removing dead, optimising} code etc. that is appreciated.

    Originally posted by deanjo View Post
    and auditor point of view.


    Auditor?

    I doubt many people did the kernel code audit. Most of the work in this field is performed by automatic tools like Coverity Prevent, Coccinelle.

    Leave a comment:


  • kebabbert
    replied
    Originally posted by Zhick View Post
    Uhm did you even have a look at the results? I got the impression that performance actually mostly improved.
    Yes I looked at every result. I suggest you look again.


    Now the 10 year old BKL is dealt with. That is good. Maybe Linux will soon start to scale better than today?
    http://www.mattheaton.com/?p=222
    "If linux wants to scale efficiently to 16,32,64 cores then the scheduler needs some serious work."

    Leave a comment:


  • deanjo
    replied
    Originally posted by Zhick View Post
    Uhm did you even have a look at the results? I got the impression that performance actually mostly improved.
    Well that depends I guess if you call resuming performance after a regression an "improvement". The only conclusion that I can really see is it depends on what performance you are looking at. Overall it's about the same IMO with a few exceptions.

    Leave a comment:


  • Zhick
    replied
    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?
    Uhm did you even have a look at the results? I got the impression that performance actually mostly improved.

    Leave a comment:


  • EarthMind
    replied
    Why no PostgreSQL benchmarks? Me is sad

    Leave a comment:


  • deanjo
    replied
    Originally posted by zouboulou View Post
    and would bring no real big benefits.
    Reducing code size and complexity always has it's benefits from a developer and auditor point of view.

    Leave a comment:

Working...
X