Page 3 of 8 FirstFirst 12345 ... LastLast
Results 21 to 30 of 75

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

  1. #21
    Join Date
    Nov 2010
    Posts
    74

    Default

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

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

  2. #22
    Join Date
    Nov 2010
    Posts
    74

    Default

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

  3. #23
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

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

  4. #24
    Join Date
    Dec 2009
    Location
    Greece
    Posts
    351

    Default

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

  5. #25
    Join Date
    Sep 2009
    Posts
    60

    Default

    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.

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

    Default

    Quote Originally Posted by TemplarGR View Post
    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...
    Guess that depends if your comparing kernels or the complete OS. Linux as a complete OS has gone up in system requirements as well over the years where as that "other OS" kernels have been developing on reducing their kernel requirements.

  7. #27
    Join Date
    Nov 2010
    Posts
    74

    Default

    Quote Originally Posted by deanjo View Post
    When coding is done right it has to be done so that making a change does not cause issues with other code.
    Hmmm... I think that you are missing a point here. Change in behavior of one function can affect other code that use this function. It's normal and you can not do anything about this. You can write unit test etc to detect breakage. Internal kernel API is fluent and such situations are normal.

    Quote Originally Posted by deanjo View Post
    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.

  8. #28
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

    Quote Originally Posted by michal View Post
    Hmmm... I think that you are missing a point here. Change in behavior of one function can affect other code that use this function. It's normal and you can not do anything about this. You can write unit test etc to detect breakage. Internal kernel API is fluent and such situations are normal.
    Not missing the point at all. Bottom line is that it still requires more work then necessary to accommodate such changes and adds to the workload which often would not be required with a reduced code base.

  9. #29
    Join Date
    Nov 2010
    Posts
    74

    Default

    Quote Originally Posted by snadrus View Post
    I'm very interested in seeing how the bisect is done.
    Read git bisect --help

    Or watch on youtube

    Quote Originally Posted by snadrus View Post
    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.
    Partially you are right. I am afraid that it is not possible to reclaim nearly any performance point ie. huge changes O(1)->CFS, SLAB->SLUB etc. But for ordinary regression it is possible - it would great if someone could actively work on this. But I am afraid that nobody wants to pay for such work

  10. #30
    Join Date
    Oct 2010
    Posts
    23

    Default

    I think the problem isn't about how big or how many legacy features are in the kernel, but more about the new features which are placed on an old architecture, maybe flesystems are too different from 5 years ago and (corrrect me if not) the srtucture of the kernel hasn't changed that fast.

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
  •