
Linux 4.17 I/O Scheduler Tests on an NVMe SSD Yield Surprising Results - rbanffy
https://www.phoronix.com/scan.php?page=article&item=linux417-nvme-io&num=1
======
Ninn
I cannot seem to see why these results are suprising? There doesnt seem to be
a conclusion stating this in the article? How were the pre 4.17 benchmarks for
the setup?

~~~
tyfon
The general consensus has been that SSDs does not have seek times in the same
way as spinning disks and does not need to reorder the writes/reads to
optimise for this, hence "none" has been recommended.

The surprise is that the others beat "none" in some situations when they in
theory just add code and write order should not matter on SSDs. Apparently
write order does matter on SSDs, at least in some situations.

I'm not switching scheduler on my drives though.

~~~
wtallis
Reordering I/O operations matters a lot for hard drives because seek times
depend on where the head is and how far it has to travel.

The effects in play for SSDs are very different. Reads are more likely to be
performance-critical than writes, so it can be beneficial to limit the number
of write operations that are in the drive's queue so that reads can be
serviced more quickly. Writes take longer than reads, but they can usually be
deferred without causing problems (though the Optane SSD in question doesn't
have a write buffer). Deferring operations also sometimes gives the drive the
opportunity to combine more host commands into a single media access.

The _order_ of commands issued to a SSD matters much less than the _number_ of
currently pending commands. If you're issuing just reads or just writes,
there's little benefit to reordering them unless they have different priority
levels (which NVMe allows through the creation of separate queues for each
priority level, but I don't think Linux currently uses this).

~~~
gregdunn
>Reads are more likely to be performance-critical than writes

Yep. I've worked with multiple environments where people were caught off guard
by seeing read latency spikes that were much higher on NVMe drives than
regular SSDs. This hit them pretty hard on database-style workloads.

Moving to utilizing the Kyber scheduler basically eliminated the latency
spikes - it allows you to set a target latency for IO operations and reorders
them to keep to those targets.

I recommend it for anyone using a blk-mq device that has a mixed read/write
workload where latency is important.

------
TheAdamist
benchmark the schedulers for your particular workload on your particular
hardware seems to be the only takeaway here.

