3 ms·

Everything I've seen say using the no-op scheduler for very low latency devices is the way to go - particularly for nvme and optane devices.. interesting that i

Everything I've seen say using the no-op scheduler for very low latency devices is the way to go - particularly for nvme and optane devices.. interesting that it doesn't seem to be mentioned here, or in the linked paper?

wtallis 5y ago
Recent Linux kernels default to not using an IO scheduler with devices that support multiple queues, which includes NVMe SSDs but not SATA (at least through AHCI HBAs). Individual distros can override the kernel's defaults. However, I'm not sure the difference between no-op and mq-deadline IO scheduling for SATA SSDs would be big enough to matter for the purposes of this article's measurements.
- anarazel 5y ago
  It's a really annoying proxy to determine the default configuration :(. There's plenty devices with multiple channels that benefits from the increased merging possible with a scheduler - particularly around writes, where a lot of consumer SSDs are weak. And conversely, there's plenty workloads on single queue devices that are hurt by the scheduler and some of the other heuristics that trigger for single queue devices...
anarazel 5y ago
FWIW, my own measurements tell a somewhat more complex story. Not hugely for reads, but writes. And less so for the higher end drives (with plenty fast cache). Plenty real world, write heavy, scenarios can benefit from having merging in positions other than head/tail (which noop can in the right circumstances). While FTLs are getting better and better, flash density is increasing (the number of QLC disks is growing, SLC ones are shrinking), and small writes are getting evermore expensive. This is especially bad for workloads involving fsync/O_DSYNC writes, because on drives with volatile caches they defeat all the efforts to shortish small write costby Of course there also a lot of write workloads that'd still never see merges, making a scheduler just unnecessary cost. This isn't helped by none of the current Linux schedulers really working well for local low latency storage. mq-deadline has completely antiquated heuristics and default constants, that clearly come from the spinning disk age. Bfq is too complicated (but works surprisingly well for higher latency / throttled storage). Nor helped by the fact that nearly every storage benchmark ensures that no merging ever will occur outside of "plugging" (basically sets of IOs submitted together). No wonder they never see any benefit from schedulers :(

wtallis 5y ago

Recent Linux kernels default to not using an IO scheduler with devices that support multiple queues, which includes NVMe SSDs but not SATA (at least through AHCI HBAs). Individual distros can override the kernel's defaults. However, I'm not sure the difference between no-op and mq-deadline IO scheduling for SATA SSDs would be big enough to matter for the purposes of this article's measurements.

anarazel 5y ago
It's a really annoying proxy to determine the default configuration :(. There's plenty devices with multiple channels that benefits from the increased merging possible with a scheduler - particularly around writes, where a lot of consumer SSDs are weak. And conversely, there's plenty workloads on single queue devices that are hurt by the scheduler and some of the other heuristics that trigger for single queue devices...

anarazel 5y ago

FWIW, my own measurements tell a somewhat more complex story. Not hugely for reads, but writes. And less so for the higher end drives (with plenty fast cache). Plenty real world, write heavy, scenarios can benefit from having merging in positions other than head/tail (which noop can in the right circumstances). While FTLs are getting better and better, flash density is increasing (the number of QLC disks is growing, SLC ones are shrinking), and small writes are getting evermore expensive. This is especially bad for workloads involving fsync/O_DSYNC writes, because on drives with volatile caches they defeat all the efforts to shortish small write costby Of course there also a lot of write workloads that'd still never see merges, making a scheduler just unnecessary cost. This isn't helped by none of the current Linux schedulers really working well for local low latency storage. mq-deadline has completely antiquated heuristics and default constants, that clearly come from the spinning disk age. Bfq is too complicated (but works surprisingly well for higher latency / throttled storage). Nor helped by the fact that nearly every storage benchmark ensures that no merging ever will occur outside of "plugging" (basically sets of IOs submitted together). No wonder they never see any benefit from schedulers :(