I fell down a bit of a rabbit hole and was reading up on I/O schedulers in Linux and it brought back fond memories of trying to eke out any little speed boost in budget Android phones back in the day.
Out of interest, I checked my current I/O scheduler and to my interest discovered it listed as “none.” I have “mq-deadline,” “kyber,” and “bfq” as options, but “none” was selected.
From what I understand, Red Hat suggests either deadline or bfq… Any ideas why we differ?
Thanks for the help!
IIRC, none is the kernel’s default for NVMe SSDs, because the overhead of host-side scheduling often just slows them down. The protocol is natively quite good at concurrent operations (per-CPU queues with something like 1023 entries, vs a single 64-entry queue with SATA NCQ), and the data is spread across a bunch of flash chips in a layout that only the SSD controller is aware of. Those chips might even have internal concurrency (Multiple planes? Something like DRAM bank groups? IDK.).
Unfortunately, it looks like it’s been a while since Phoronix tested I/O schedulers, but in the lastest article I was able to find, there were several tests where none blew the doors off everything else.
Thanks for the interesting and insightful response!
In addition to R Haley’s comments, bfq aims to reduce latency “as much as possible” in expense of slower I/Os. Making a more snappy experience in hardware with slower speeds. Mq-deadline commnly proves to be the best choice for hard drives instead of ssd where the rotation of the hard drive must match with the I/O ( in extremely simplified terms ).