Aug 6 2011

I have an SSD-equipped Asus Eee that I use as my main laptop. Unfortunately the Phison SSDs shipped with the Eee suffer from staggeringly low random write performance. Under load latencyTOP would show several seconds (!) of latency. Some of these issues had cleared up when I upgraded to 2.6.38, but there were a few spikes here and there.

Previously I had been using the deadline IO scheduler because it tends to have increased performance with respect to CFQ on SSDs. I didn’t want to use noop because I actually was optimizing the system for latency; while noop tends to have greater throughput, I was optimizing for latency. For aggregate latency, deadline should be the best performing scheduler on SSDs. However, in my case I don’t care about aggregate latency, I only care about the latency of programs I actually use. This is where both deadline and noop fail.

Strangely, for this kind of service we want to return to CFQ. Not only does it try to schedule based on nice levels, but it also can schedule based on classes of traffic specified by ionice. For example, my backup software tends to generate a lot of read/write traffic in the background. While the reads do little harm, the writes tax my poor SSD and cause the multi-second latencies described above. This has been partially documented here. To help alleviate the problem, I can run SpiderOak like so:

ionice -c3 nice SpiderOak

This sets the application to have low CPU and I/O priority. The -c3 means the ‘idle’ class; its I/O operations won’t run unless nothing else is using the system. While I have no hard data, I have noticed a noticable drop in latency for other applications with this scheme set up. Note that noop and deadline fundamentally can’t support this kind of I/O scheduling; also note that this advice only applies for SSDs which have poor write performance: cheap laptop and phone SSDs in particular. Most desktop SSDs have significant caching and TRIM support which boost random write speed high enough to remove most concerns. With these drives, using noop or deadline makes a lot of sense.

Most distributions have CFQ as the default IO scheduler. If you’re not sure, you can run this to check:

cat /sys/block/sda/queue/scheduler

To set things to CFQ run:

sudo -i
echo cfq > /sys/block/sda/queue/scheduler
echo 0 > /sys/block/sda/queue/rotational

Obviously adjust sda to correspond the drive you are adjusting settings for. The second line hints to the scheduler that you are using an SSD (instead of a rotational drive) and that it should not attempt to “anticipate” IO coming in on the same drive track.