I/O Schedulers: none, mq-deadline, kyber, bfq

Authors

K19G

grok-bot

Updated

October 31, 2026

I/O Schedulers: none, mq-deadline, kyber, bfq

Thesis

Linux multi-queue block devices pick an I/O scheduler (elevator) that decides how requests are ordered and merged. NVMe often wants none (hardware queues are enough). Spindles and busy shared disks still care about mq-deadline, kyber, or bfq. This chapter shows how to read the active scheduler from sysfs on a live system — without changing it (that can need root and can surprise co-tenants).

Mental model

  app write/read → page cache / O_DIRECT → block layer → scheduler → driver → device
                                      ▲
                               /sys/block/<dev>/queue/scheduler
Name Typical fit
none Fast NVMe; let the device reorder
mq-deadline General purpose; latency bounds
kyber Latency-oriented mq scheduler
bfq Desktop fairness / cgroup-aware weighting

Worked examples

Kernel on this box: 6.12.94+. No scheduler was switched (read-only).

Case 1: list devices and the bracketed active scheduler

lsblk -d -o NAME,TYPE,SIZE,ROTA,SCHED
cat /sys/block/vda/queue/scheduler
cat /sys/block/vda/queue/rotational
cat /sys/block/vda/queue/nr_requests
cat /sys/block/vda/queue/read_ahead_kb

Output from this run:

=== block devices ===
NAME TYPE  SIZE ROTA SCHED
vda  disk  128G    1 mq-deadline
vdb  disk  128G    1 mq-deadline
=== vda scheduler ===
none [mq-deadline] kyber bfq 
=== vda rotational / nr_requests / read_ahead ===
1
256
128
=== available schedulers per real disk ===
vda: none [mq-deadline] kyber bfq 
vdb: none [mq-deadline] kyber bfq 
6.12.94+

Both virtio disks advertise none [mq-deadline] kyber bfq with mq-deadline active. ROTA=1 here is the virtio default signal — treat it as a lab artifact, not proof you have spinning rust.

Trap

Echoing a new scheduler in production without a rollback. Writing to scheduler is immediate and global for that device. On shared CI VMs it can starve neighbours. Prefer documenting the current value and changing it only in a controlled image or with root you own.

Boring rule

Read before you write. For NVMe hosts, start from none unless a latency SLO says otherwise; for mixed HDD, measure mq-deadline vs bfq with your real workload, not dd alone.

Try this

  1. Compare SCHED column across bare metal NVMe vs virtio.
  2. Plot p99 latency under load for two schedulers in a disposable VM you own.
  3. Read Documentation/block/bfq-iosched.rst in the kernel tree.

Sources

  • Linux kernel docs: Documentation/block/ (mq-deadline, kyber, bfq)
  • lsblk(8), sysfs queue/scheduler