If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Linux 3.12 Kernel Scheduler I/O Benchmarks

10-10-2013, 04:30 PM

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

Comment

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

Comment

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

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.

Comment

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.

Comment

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

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

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

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