Use the kyber I/O scheduler on real disks

The kernel leaves NVMe on none and everything else on mq-deadline. Neither
bounds latency once the device queue fills, so a large build, copy, or
package upgrade can make the desktop sluggish while reads wait behind a
wall of writes.

Kyber keeps separate read and sync-write queues and throttles the depth it
submits to hit a 2ms read target, which keeps interactive reads flowing
under heavy writes at negligible CPU cost. The trade is a small ceiling on
peak throughput on very fast devices, which matters for a storage server
chasing IOPS but not for a desktop.

Ships as a package-owned udev rule in /etc so it applies at boot and on
hot-plug. Existing installs pick it up at the next boot. zram is left alone
since it has nothing to schedule.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
David Heinemeier HanssonandClaude Fable 5.1 committed 2026-09-13 11:53:27 +02:00
1 parent 93d9d0c859
commit dae1f4bf0e
1 file changed
+6
@@ -0,0 +1,6 @@
# Kyber targets read latency (2ms) and throttles writes to hold it, so the
# desktop stays responsive under a large build, copy, or package upgrade.
# The kernel default is none for NVMe and mq-deadline for everything else,
# neither of which bounds latency once the device queue fills. Applies to real
# disks only; zram is memory and has nothing to schedule.
ACTION=="add|change", KERNEL=="nvme[0-9]*n[0-9]*|sd[a-z]*|mmcblk[0-9]*|vd[a-z]*", ATTR{queue/scheduler}="kyber"