After my previous post, I investigated a bit further by changing one single compilation option as a reader suggested. Instead of running “make“, I ran “make -j 3” to run 3 compilation threads in parallel on my Core 2 Duo system. The results are quite surprising…
First of all, I ran my previous benchmarks again and the results were confirmed with a 17% gain for the NOOP scheduler. Then things got bad 
When running in a much more disk-intensive “make -j 3” mode, I got the following results for 2 benchmark passes:
- 1481 and 1566 seconds for NOOP
- 1202 and 1256 seconds for CFQ
That’s a 23% and 24% difference in favor of CFQ!
A very likely explanation to this problem might be that my SSD controller likes sequential accesses:
- When you are in NOOP mode, it’s a simple FIFO: you request a file and you get it, same goes for writing. When you do the same with 3 threads, the disk controller may get lost quite quickly, and its efficiency drops dramatically.
- When you are in CFQ mode with your 3 threads simultaneously accessing files, the CFQ algorithm kicks in as on a normal hard disk and tries to limit the movements of your now “virtual” disk head and grouping data by 64, 128 or 256k blocks (wild guess here). This probably helps to improve access linearity.
So, what can we say in the end? Only one thing I’m afraid, selecting the right I/O scheduler corresponding to your SSD and your computer usage can lead to an I/O performance gain of almost 25% if you look at the worst vs. best case scenario, but there is no rule for this. CFQ as the default scheduler seems to be the best solution anyways. In my use case, NOOP fits me better.
To be not cpu limited, try to bench only the decompression speed of the big tar.gz file. Usualy random write are quite bad on cheap SSD (!= intel) that should be a good test. (random write)
Nice article, though NOOP is not much of a scheduler. Which is i guess, why you were testing it
Since you posted a followup, what about another one with “elevator=deadline” as well as “echo 1 > /sys/block/sdX/queue/iosched/fifo_batch” to reduce read/write grouping.
Cheers
mAAddog
Honestly, I don’t have much time for that right now.
Well it will make a good part 3 if you ever do
for those of us with spindles still, NCQ disk access coupled with elevator=noop is suggested to allow the hardware to do fine grained elevator control which is defeated by IO scheduling at the kernel layer. fwiw. i’d stick with noop on gp, for SSD too, however, for anything but server loads.