SSD performance vs Linux kernel I/O scheduler in Fedora 10

As you have probably read, I bought a new laptop with an SSD drive recently, a Lenovo x301. Today I opened my SSD to see what’s inside and it turns out Lenovo is using quality drives. They are manufactured by Samsung, which use a decent I/O controller and cache memory contrary to the cheap drives you can buy these days which use lousy JMicron JMF602 controllers (Like the OCZ Core series). I started to wonder if I could gain even more performance…

SSD drive from a Lenovo x301

On a forum, a friend told me to also have a look at the I/O scheduler used by the Linux kernel, he heard that you could gain some performance out of SSD drives by playing with it. Not knowing what he was talking about, I began to do some research…The first thing I came across was a Red Hat article explaining what the 4 I/O schedulers available in modern (~ post 2.6.10) Linux kernels were.

There are basically 4 algorithms you can select to control the way your data is saved/read from your disks. The default one used in Fedora 10 is called “Completely Fair Queuing” and was primarely designed with standard mechanical disks in mind. When you move data around, it tries to determine an optimal access path to minimize your hard disk’s heads movements. With SSDs we don’t have this problem anymore because the access time is constant across all the drive, so the whole computing part which takes resources is superfluous.

To know which scheduler is currently active on your disk (let’s say sda), you can run the “cat /sys/block/sda/queue/scheduler” command. The one in brackets is what’s active.

noop anticipatory deadline [cfq]

With this setting, I started to run some benchmarks, basically a little shell script uncompressing and compiling a default 2.6.28.2 Linux kernel…nothing fancy. It outputs a total time in seconds.

#!/bin/bash
START=$(date +%s)
tar -jxf linux-2.6.28.2.tar.bz2
cd linux-2.6.28.2
make
STOP=$(date +%s)
TOTAL=$(($STOP – $START))
echo $TOTAL

With the CFQ scheduler, it took 4161 seconds to compile the kernel.

Then I switched to the “NOOP” scheduler, which is just a “stupid” but fast FIFO algorithm who relies on the physical disk’s controller to optimize the accesses. So there is no CPU calculation overhead here. To switch to this algorithm, simply append “elevator=noop” to the kernel line in your grub.conf.

With the NOOP scheduler, it took only 3653 seconds to compile the kernel, that’s a 13% time gain!

So, what can we say? That wih a good SSD drive (one which has a good controller), it’s really worth playing with these settings if you have time. For a desktop user I’m never going to do something more I/O intensive than a kernel compilation, so a permanent 10-15% gain in I/O performance is really sweet.

Controller and cache on the Samsung MMCQE28G8MUP-0VA SSD