Announcement

Collapse
No announcement yet.

Linux 3.12 Kernel Scheduler I/O Benchmarks

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

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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Michael, a comparison against BFS would be nice.

    Comment


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

      Comment


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

        Comment


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


          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; 11 October 2013, 01:29 AM.

          Comment


          • #6
            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.
            All opinions are my own not those of my employer if you know who they are.

            Comment


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

              Comment


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

                Comment


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

                  Comment


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

                    Comment

                    Working...
                    X