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

Question

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?

Answer 1

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.