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

  • #21
    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.

    Comment


    • #22
      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.

      Comment


      • #23
        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.

        Comment


        • #24
          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...

          Comment


          • #25
            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.

            Comment


            • #26
              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.

              Comment


              • #27
                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.

                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.

                Comment


                • #28
                  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.

                  Comment


                  • #29
                    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

                    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

                    Comment


                    • #30
                      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.

                      Comment

                      Working...
                      X