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

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

    Comment


    • #17
      Why no PostgreSQL benchmarks? Me is sad

      Comment


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

        Comment


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

          Comment


          • #20
            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."

            Comment


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