Announcement

Collapse
No announcement yet.

Linux 2.6.32 Kernel Benchmarks

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

  • phoronix
    started a topic Linux 2.6.32 Kernel Benchmarks

    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

  • Apopas
    replied
    So only SMP systems should see encoding benefits with 2.6.32?

    Leave a comment:


  • Kano
    replied
    Well BFS increases compile speed by about 5% with the same number of threads. 7zip should be also a good benchmark for this, but single core benchmarks are useless to show multicore speed.

    Leave a comment:


  • Apopas
    replied
    I installed 2.632 just now and run some tests to compare 2.6.31-r6 vs 2.6.32.
    I repeated each one 4 times and these are the average scores:

    lame
    0m59.607s ---> 2.6.31-r6
    0m59.639s ---> 2.6.32


    oggenc
    0m24.844s ---> 2.6.31-r6
    0m24.480s ---> 2.6.32


    x264
    1m50.563s with 30.80 fps ---> 2.6.31-r6
    1m51.355s with 30.58 fps ---> 2.6.32


    In other worlds bullshits. Where's the speed improvement in x264?
    Should I enable something specific in kernel?

    Leave a comment:


  • Picander
    replied
    Starting by looking at the CPU usage during the playback of a 1080p H.264 video file, the Linux 2.6.32 kernel had the lowest overall CPU usage when using X-Video with MPlayer. However, the CPU usage was only less by 2%.
    Looks like there is an error! The graph says
    2.6.30 = 32.3
    2.6.31 = 37.2
    2.6.32 = 39.1

    Leave a comment:


  • kraftman
    replied
    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, 11:56 AM.

    Leave a comment:


  • Kano
    replied
    Maybe 2.6.31+BFS and 2.6.32+BFS should be added to compare.
    Last edited by Kano; 11-29-2009, 08:46 PM.

    Leave a comment:


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

    Leave a comment:


  • kraftman
    replied
    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.

    Leave a comment:


  • Veerappan
    replied
    Originally posted by Ranguvar View Post
    Well, CK and Dark Shikari. http://x264dev.multimedia.cx/?p=185

    @Phoronix team:

    Not lowest. Either 'worst', or 'highest'.
    Agreed. I looked at the graph, then the comments, and then back at the graph a few times... The average CPU utilization is higher almost across the board, but the PEAK utilization was lower for 2.6.32.

    So I guess Michael's technically right, but the text analysis doesn't lead one to look at the average numbers, both of which are important in video playback.

    Leave a comment:

Working...
X