SSD and CFQ - why not, it has support for it

Clouseau · 2014-12-12 15:05:06

Hello,

in wiki its stated it is better to switch to deadline or noop instead of default cfq scheduler for SSD disks. But, I quote:
""CFQ has some optimizations for SSDs and if it detects a non-rotational
media which can support higher queue depth (multiple requests at in
flight at a time), then it cuts down on idling of individual queues and
all the queues move to sync-noidle tree and only tree idle remains. This
tree idling provides isolation with buffered write queues on async tree."

https://www.kernel.org/doc/Documentatio … osched.txt

So why change to deadline or noop?

graysky · 2014-12-12 15:22:18

It's a wiki, and the contents weren't etched into stone tables as though they are the word of God... if you feel the advice is bad or ill-informed, you can flag that section of the wiki as such and encourage a discussion.

For wiki templates (including accuracy), see: https://wiki.archlinux.org/index.php/Sp … dTemplates

Last edited by graysky (2014-12-12 15:23:28)

Clouseau · 2014-12-12 16:09:27

Sorry, didn't mean to bash on wiki, the information that is stated there are reoccuring aroung the web. I just wanna hear what people think regarding cfq for ssd's.

Btw. I'm over 4 years on the same install of Arch, on two computers, up to date is and the distro totally rocks, it is freeking bleeding edge but it's very stable. I've moved after year and a half on Gentoo and I think this is the best distro to have on a desktop computer (if you know your way in terminal)...

WonderWoofy · 2014-12-13 06:21:44

In my very informal and non-scientific testing, I have found that cfq is slightly slower than the others. That said, SSDs are fast... and I don't actually notice a difference between the schedulers in any kind of usage. So I just stick with the default.

Clouseau · 2014-12-14 11:38:34

I have found this http://www.phoronix.com/scan.php?page=a … 16_iosched

CFQ does have some optimizations for SSD but deadline is still faster. You are quite right and I agree that in desktop use the difference between the two is not noticable...

anatolik · 2014-12-23 22:12:21

Before discussing IO schedulers and what they are needed for let's look at a rotational device (HDD, spindle). Such device has spinning disks and head that physically moves to required location. Such structure leads to following characteristics:
- random latency it quite high, for modern HDD it is ~10ms (let's ignore disk controller write buffer).
- sequential access provides much higher throughput. In this case head needs to move less distance.

In case if we have a lot of running processes that make IO requests to different parts of storage (i.e. random access) then we can expect that a disk handles ~100 IO per second. Because modern systems can easily generate load much higher than 100 req/sec we have a queue of requests that have to wait for access to the storage. One way to improve throughput is to linearize access i.e. order waiting requests by its logical address and always choose closest request. Historically this was the first linux IO scheduler called elevator scheduler.

One of the problems with elevator algorithm is that it makes suffer processes with sequential access. Such processes read a block of data then process it for several microseconds then read next block and so on. Elevator scheduler does not know that the process is going to read another block nearby and thus to moves to another request at some other location. To overcome the problem anticipatory IO scheduler was added. For synchronous requests this algorithm waits for a short amount of time before moving to another request.

While these scheduler try to improve total throughput they also might leave some unlucky requests waiting for a very long time. Imagine majority of processes make requests at the beginning of storage space while an unlucky process makes process at the other end of storage. So developers tried to make algorithm more fair. Thus deadline scheduler was added. It has a queue ordered by address (the same as elevator). If some request sits in this queue for a long time then it moves to "expired" queue ordered by expire time. Scheduler check expire queue first and process requests from there and only then moves to elevator queue. It is important to understand that this algorithm scarifies total throughput for fairness.

CFQ (the default scheduler nowdays) aggregates all ideas from above and adds cgroup support that allows to reserve some amount of IO to a specific cgroup. It is useful on shared (and cloud) hostings - users who paid for 20 IO/s want to get their share if needed.

Now let's look at characteristics of SSD. It does not have moving parts. Random access as fast as sequential one. SSD can handle multiple requests at the same time. Modern devices' throughput ~10K IO/s that is higher than workload on most systems. Essentially user cannot generate enough requests to saturate SDD, the requests queue is effectively always empty. In this case IO scheduler does not provide any improvements. Thus it is recommended to use noop scheduler for SSD.

As for phoronix benchmarking - its results look sketchy to me. I would expect that noop is slightly better than deadline with difference at the measurement noise level.

Arch Linux

#1 2014-12-12 15:05:06

SSD and CFQ - why not, it has support for it

#2 2014-12-12 15:22:18

Re: SSD and CFQ - why not, it has support for it

#3 2014-12-12 16:09:27

Re: SSD and CFQ - why not, it has support for it

#4 2014-12-13 06:21:44

Re: SSD and CFQ - why not, it has support for it

#5 2014-12-14 11:38:34

Re: SSD and CFQ - why not, it has support for it

#6 2014-12-23 22:12:21

Re: SSD and CFQ - why not, it has support for it

Board footer