Page 1 of 3 123 LastLast
Results 1 to 10 of 21

Thread: Linux 2.6.32 Kernel Benchmarks

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,107

    Default Linux 2.6.32 Kernel Benchmarks

    Phoronix: Linux 2.6.32 Kernel Benchmarks

    With the Linux 2.6.32 kernel being released in a few days, we found it time to benchmark this newest kernel release that brings new drivers, kernel mode-setting improvements, virtualization enhancements, and more.

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

  2. #2
    Join Date
    Jan 2009
    Posts
    206

    Default

    I'm starting to think that those big boys should really start testing and profiling their crap. I wonder how 2.6.24 would compare. Good article.

  3. #3
    Join Date
    Oct 2009
    Posts
    213

    Default

    Quote Originally Posted by hax0r View Post
    I'm starting to think that those big boys should really start testing and profiling their crap. I wonder how 2.6.24 would compare. Good article.
    I asbolutely quote here.

  4. #4

    Default

    Quote Originally Posted by hax0r View Post
    I'm starting to think that those big boys should really start testing and profiling their crap. I wonder how 2.6.24 would compare. Good article.
    They actually do, but they also do proper benchmarks. I wonder if generic kernels were tested here and still ext4 vs different mount options (or mentioned commit which changed behavior) and maybe even different settings like NO_NEW_FAIR_SLEEPERS which is default in Karmic and it affects benchmarks numbers. Btw, what are you talking about if it was planned change?

    And like Michael pointed:

    The very significant drop in PostgreSQL's performance in the Linux 2.6.32 kernel with default options can be attributed to this lone Git commit that is for a fix to address cache flushing in ext4_sync_file for the EXT4 file-system. This commit improves data integrity in the event of a power loss or other problem, but carries a high disk performance penalty.
    Last edited by kraftman; 11-28-2009 at 05:17 AM.

  5. #5
    Join Date
    Oct 2007
    Posts
    34

    Default

    It should be noted than on 2.6.32, both the CPU and the I/O schedulers have been tuned for desktop usage (i.e, low latency), which means a drop in throughput in many cases. But desktop users should "feel" things faster, more responsive.

    So nothing to worry about here, on the contrary, it just proves that the kernel devs did a bold movement in favour of desktop users.

  6. #6

    Default

    Quote Originally Posted by Luis View Post
    It should be noted than on 2.6.32, both the CPU and the I/O schedulers have been tuned for desktop usage (i.e, low latency), which means a drop in throughput in many cases. But desktop users should "feel" things faster, more responsive.
    Yes, but I/O scheduler will be probably set for throughput for final 2.6.32. Afaik it's set for low latency in -rc and some benchmarks suffer from this. It should be optimized and set default for 2.6.33.

    So nothing to worry about here, on the contrary, it just proves that the kernel devs did a bold movement in favour of desktop users.
    Yes, if someone wants to have good results in some benchmarks just mount file system using different mode or options.

  7. #7
    Join Date
    Mar 2009
    Location
    Hellas
    Posts
    1,098

    Default

    I wonder if this boost is just for x264 or if we are gonna see sweet results with lame and oggenc as well

  8. #8

    Default

    Quote Originally Posted by kraftman View Post
    Yes, but I/O scheduler will be probably set for throughput for final 2.6.32. Afaik it's set for low latency in -rc and some benchmarks suffer from this. It should be optimized and set default for 2.6.33.
    I/O scheduler is set for low latency in the final 2.6.32 and this can have impact on some benchmarks. From kernel newbies:

    In this release, the CFQ IO scheduler (the one used by default) gets a new feature that greatly helps to reduce the impact that a writer can have on the system interactiveness. The end result is that the desktop experience should be less impacted by background IO activity, but it can cause noticeable performance issues, so people who only cares about throughput (ie, servers) can try to turn it off echoing 0 to /sys/class/block/<device name>/queue/iosched/low_latency. It's worth mentioning that the 'low_latency' setting defaults to on.
    http://kernelnewbies.org/LinuxChange...231eaf58a63ed8
    Last edited by kraftman; 12-03-2009 at 10:56 AM.

  9. #9
    Join Date
    Mar 2009
    Location
    Hellas
    Posts
    1,098

    Default

    This x264 boost is rather interesting, but this postmark and iozone regressions are due to the ext4 "problem"?

  10. #10
    Join Date
    Jan 2009
    Location
    UK
    Posts
    331

    Default

    Quote Originally Posted by Apopas View Post
    This x264 boost is rather interesting, but this postmark and iozone regressions are due to the ext4 "problem"?
    No idea what's wrong with ext4, but Con Kolivas needs three cheers for getting them to finally fix their damn scheduler.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •