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...
Michael, a comparison against BFS would be nice.
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?
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.
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.
Originally Posted by Rallos Zek
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?
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.
Originally Posted by Ericg
But I have not done much USB disk copying in many years.
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.
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