Announcement

Collapse
No announcement yet.

Linux 2.6.30 Kernel Benchmarks

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux 2.6.30 Kernel Benchmarks

    Phoronix: Linux 2.6.30 Kernel Benchmarks

    With the Linux 2.6.30 kernel being prepped for release in early June, we have set out to provide a few benchmarks of this latest Linux kernel to see how it compares to its two earlier predecessors. While this new kernel may offer support for new file-systems (NILFS2, in particular), support for LZMA/BZIP2 kernel image compression, a new CPU architecture (Microblaze) and many other changes, are there any major performance regressions or improvements like we have spotted with our previous Linux kernel benchmarks?

    http://www.phoronix.com/vr.php?view=13891

  • #2
    The 4GB write performance is really interesting, but why this 7z compression regression?

    Comment


    • #3
      It would be really interesting if some kernel developers looked at the regressions and bisected them.

      Hell, I might even do it myself if I find the time this weekend.

      Comment


      • #4
        It would add a lot to the article if you could at least attempt to explain the instances where there are large performance changes.

        Comment


        • #5
          Originally posted by Apopas View Post
          why this 7z compression regression?
          because the kernel is getting fat

          Comment


          • #6
            So? fat ones are beautiful

            Comment


            • #7
              I have been running this kernel for a few days on Ubuntu Intrepid and it 'feels' faster than 2.6.28 from a desktop usage standpoint.

              My main drive is encrypted, so maybe I am just seeing performance improvements similar to GnuPG benchmark, but either way I like it.

              Comment


              • #8
                These test should be done with 64bit too. On gentoo, we found 2.6.30 over 600% faster in most intensive I/O load (like decompression). A 3 years old (introduced in 2.6.16) regression have been fixed.

                Comment


                • #9
                  Originally posted by Elv13 View Post
                  These test should be done with 64bit too. On gentoo, we found 2.6.30 over 600% faster in most intensive I/O load (like decompression). A 3 years old (introduced in 2.6.16) regression have been fixed.
                  I believe that the first page of the article mentioned that the testing was performed using Ubuntu 9.04 x86-64.

                  Comment


                  • #10
                    Originally posted by Elv13 View Post
                    These test should be done with 64bit too. On gentoo, we found 2.6.30 over 600% faster in most intensive I/O load (like decompression). A 3 years old (introduced in 2.6.16) regression have been fixed.
                    From the article:

                    With the Linux 2.6.28, 2.6.29, and 2.6.30-rc7 kernels we obtained the x86_64 vanilla kernels from the Ubuntu mainline kernel PPA.
                    Michael Larabel
                    http://www.michaellarabel.com/

                    Comment


                    • #11
                      It is really something wrong with all the kernels > 2.6.20. I get results with the threaded io write test with 64MB and 32 threads about 500ms with 2.6.20 kernel. While the kernel 2.6.29 kernels returns times about 2.500ms on my machine. I have remove the smp support on my Core2 Duo @ 2.4GHz to minimize scheduler differences. Both kernels are vanila kernels.

                      Comment


                      • #12
                        With the Linux 2.6.28, 2.6.29, and 2.6.30-rc7 kernels we obtained the x86_64 vanilla kernels from the Ubuntu mainline kernel PPA.
                        Well dammit it should have been ran on a FUJITSU VENUS SPARC64 VIIIFX dammit. These results are completely invalid.

                        Comment


                        • #13
                          AFAIK they changed some default mount options for ext3 - all fs 'improvements' - aka dbench, can be nicely explained by this. Less secure, more 'performance'.

                          I will stay with reiser4 - the fs that cares about data.

                          Comment


                          • #14
                            Originally posted by energyman View Post
                            AFAIK they changed some default mount options for ext3 - all fs 'improvements' - aka dbench, can be nicely explained by this. Less secure, more 'performance'.

                            I will stay with reiser4 - the fs that cares about data.
                            Well so does btrfs supposedly. Fortunately, with ext and probably reiser too you can adjust the options to favor data integrity over speed, if you don't like it, AFAIK.

                            Comment


                            • #15
                              which is stupid. Save should be default. If someone needs speed, he can tweak. Being fast-but-unsecure is nice for benchmarks - and horrbile wrong in real life.

                              ext3 has barriers off per default - idiotic. And now unsafe options by default - more idiotic. It only shows that extX devs don't care about their users data. Only benchmarks.

                              Comment

                              Working...
                              X