Selecting the right Linux I/O scheduler for a host equipped with NVMe SSD?

Question

We are writing a highly concurrent software in C++ for a few hosts, all equipped with a single ST9500620NS as the system drive and an Intel P3700 NVMe Gen3 PCIe SSD card for data. Trying to understand the system more for tuning our software, I dug around the system (two E5-2620 v2 @ 2.10GHz CPUs, 32GB RAM, running CentOS 7.0) and was surprised to spot the following:

[root@sc2u0n0 ~]# cat /sys/block/nvme0n1/queue/scheduler 
none

This contradicts to everything that I learned about selecting the correct Linux I/O scheduler, such as from the official doc on kernel.org.

I understand that NVMe is a new kid on the block, so for now I won't touch the existing scheduler setting. But I really feel odd about the "none" put in by the installer. If anyone who has some hints as to where I can find more info or share your findings, I would be grateful. I have spent many hours googling without finding anything concrete so far.

Answer 1

"none" (aka "noop") is the correct scheduler to use for this device.

I/O schedulers are primarily useful for slower storage devices with limited queueing (e.g, single mechanical hard drives) — the purpose of an I/O scheduler is to reorder I/O requests to get more important ones serviced earlier. For a device with a very large internal queue, and very fast service (like a PCIe SSD!), an I/O scheduler won't do you any good; you're better off just submitting all requests to the device immediately.

Answer 2

The answer given by Sanne in the comments is correct:

"The reason is that NVMe bypasses the scheduler. You're not using the "noop" implementation: you're not using a scheduler."

noop is not the same as none, noop still performs block merging (unless you disable it with nomerges)

If you use an nvme device, or if you enable "scsi_mod.use_blk_mq=Y" at compile time or boot time, then you bypass the traditional request queue and its associated schedulers.

Schedulers for blk-mq might be developed in the future.