Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Linux 3.12 Kernel Scheduler I/O Benchmarks

  1. #1
    Join Date
    Jan 2007
    Posts
    14,904

    Default Linux 3.12 Kernel Scheduler I/O Benchmarks

    Phoronix: Linux 3.12 Kernel Scheduler I/O Benchmarks

    Our latest benchmarks of the Linux 3.12 kernel are looking at the I/O performance between the Noop, CFQ, and Deadline schedulers on the latest Linux kernel when using the high-end Intel Core i7 4960X...

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

  2. #2
    Join Date
    Sep 2012
    Posts
    289

    Default

    Michael, a comparison against BFS would be nice.

  3. #3
    Join Date
    Mar 2011
    Posts
    92

    Default

    I must say from those tests I can not decide which one is better as they are in almost every case identical. Only one that really stands out is first compile bench. I wonder where this 15% difference came from - 65 to 75 MBs between best and worst result

    Anyways how about adding BFQ results as well?

  4. #4
    Join Date
    May 2012
    Posts
    826

    Default

    BFS ain't about speed, it's about the desktop staying responsive.

    To this day the Linux kernel/OS randomly becomes worn out after I/O apparently because Linus wants the same scheduler to run on all setups, be it a supercomputer cluster or a PC, he deserves to be called an asshole for that.

  5. #5
    Join Date
    Sep 2011
    Posts
    158

    Default

    Quote Originally Posted by mark45 View Post
    BFS ain't about speed, it's about the desktop staying responsive.

    To this day the Linux kernel/OS randomly becomes worn out after I/O apparently because Linus wants the same scheduler to run on all setups, be it a supercomputer cluster or a PC, he deserves to be called an asshole for that.
    Have proof of this behavior and can you trigger it? Many have made this claim none have proved it. If you cannot back up this claim you must be the Asshole not Linus.


    Quote Originally Posted by wargames View Post
    Michael, a comparison against BFS would be nice.
    BFS is not a I/O Scheduler.
    Last edited by Rallos Zek; 10-11-2013 at 01:29 AM.

  6. #6
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,900

    Default

    Quote Originally Posted by Rallos Zek View Post
    Have proof of this behavior and can you trigger it? Many have made this claim none have proved it. If you cannot back up this claim you must be the Asshole not Linus.
    Everyones who's made this claim...can back it up. Because its SUPER easy to recreate o.O Its just impossible to diagnose as to WHY and what part of the scheduler logic gets tripped up. I can recreate it without fail everytime I do a backup. Couple hundred gigs being transferred over USB to an external hard drive from my home folder. Bam. During the entire copy my system is completely unresponsive. Activating the desktop menu can take 10seconds or more, right clicks 5 seconds or more. You name it, it slows to a crawl.

  7. #7
    Join Date
    Jan 2008
    Posts
    155

    Default

    The thing is : is it a problem of the kernel IO scheduler or a problem of the DE.
    I sometimes experience the behaviour you describe. Funily, in these situation, if I have an opened console available, I can usually type commands without being really slowed down, while indeed opening the menu is slow. The difference, in my opinion, is that opening the menu actually make an IO request to read some XML file and this IO is delayed. And since in the case of KDE, I seem to remember that plasma is not completely multithreaded (quite remote memory, could be wrong here), it makes the whole Plasma desktop stall for a while. But would that be an issue with the kernel or with the Plasma desktop?

  8. #8
    Join Date
    Sep 2011
    Posts
    158

    Default

    Quote Originally Posted by Ericg View Post
    Everyones who's made this claim...can back it up. Because its SUPER easy to recreate o.O Its just impossible to diagnose as to WHY and what part of the scheduler logic gets tripped up. I can recreate it without fail everytime I do a backup. Couple hundred gigs being transferred over USB to an external hard drive from my home folder. Bam. During the entire copy my system is completely unresponsive. Activating the desktop menu can take 10seconds or more, right clicks 5 seconds or more. You name it, it slows to a crawl.
    I will have to do test that out one of these days. I know about desktop freezing when heavy copy/write operations are going on, but I have failed to come across any OS that does not slow down when this happens. Just last month I had FreeBSD and it slows down just as much as Windows, Linux or Haiku/BeOS. So I do not know what can mitigate against this problem in Linux itself.

    But I have not done much USB disk copying in many years.

  9. #9
    Join Date
    Sep 2012
    Posts
    289

    Default

    The desktop also freezes in Windows 7 under heavy I/O. I see this all the time when running Blender or Firefox on Windows, you get the typical "not responding" message on the app's window. There's nothing you can about it besides buying a SSD, then it flies.

  10. #10
    Join Date
    Aug 2013
    Posts
    4

    Default NGINX vs Apache

    As far as I can tell, there's really not much to see here, except for one thing.
    One thing i noticed though, was the differences between NGINX and Apache, 27000 vs 17000 pages served.
    I'm no web server expert, but are there really that much of a difference in normal usecases?
    Usually benchmarks are not all that comparable to real world performance, but this difference seems huge to me.
    Serving a web page is serving a webpage, right? So they should be quite equal, performance-wise?
    If anyone can enlighten me on this, it would be much appreciated, as I don't see why Apache would have such a large market share if the performance gap was this big

Posting Permissions

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