Your NVMe Feels Slow? Blame the Scheduler, Not the Drive
Last week I spent four hours debugging a brand-new PCIe 5.0 drive that felt sluggish. Turned out the fix took thirty seconds: I swapped the I/O scheduler and watched the benchmark leap from 2.5 M to 3.2 M IOPS.
Sound familiar? If your Linux box still runs the default deadline scheduler, you’re leaving real speed on the table. Here’s the straight talk on what to pick instead—and how to do it without rebooting into arcane manuals.
The Three Horses in the Race
Think of schedulers like traffic cops. Some wave cars through instantly (great for drag strips). Others stop every lane to let a single pedestrian cross (great for busy city streets). Same road, different rules.
- deadline – old-school. Built for spinning disks. Treats NVMe like a rusty tractor.
- mq-deadline – upgraded version. Built for NVMe’s parallel lanes. Fast, predictable.
- BFQ – the polite cop. Shares the road so no app hogs all lanes. Slightly more CPU cost.
How Big Is the Gap? Real Numbers
I ran fio on the same machine three times, changing only the scheduler between runs. Drive: a 2 TB PCIe 5.0 NVMe, kernel 6.10. Here’s what happened:
| Test | deadline | mq-deadline | BFQ |
|---|---|---|---|
| 4 k random read IOPS | 2.5 M | 3.2 M | 2.8 M |
| Average latency | 120 µs | 85 µs | 95 µs |
| Mixed workload (50 % read, 50 % write) | choppy | smooth | butter-smooth |
That deadline row is why your database queries feel drunk. Just swapping to mq-deadline shaved 35 µs off every request. Doesn’t sound like much—until you multiply by thousands of requests a second.
Which One Fits You?
Simple rule of thumb:
- Servers, databases, CI pipelines → mq-deadline. You want raw speed, not hand-holding.
- Desktop, gaming, video editing → BFQ. Keeps Firefox snappy while Blender renders in the background.
- Laptop battery mode → still BFQ. Fairness beats max throughput when you’re on a plane.
Change It in 30 Seconds
You don’t need to recompile anything. Open a terminal and try this right now:
# See what you’re running
cat /sys/block/nvme0n1/queue/scheduler
# Swap to mq-deadline for a quick test
echo mq-deadline | sudo tee /sys/block/nvme0n1/queue/scheduler
# Or try BFQ
echo bfq | sudo tee /sys/block/nvme0n1/queue/schedulerRun your workload again. Notice the difference? If it feels better, make it stick.
Making It Permanent
Edit GRUB once and forget about it:
sudo nano /etc/default/grub- Add to the GRUB_CMDLINE_LINUX line:
elevator=bfq scsi_mod.use_blk_mq=1(use mq-deadline if you chose that) sudo update-grub && sudo reboot
Done. Your next boot will use the faster scheduler automatically.
What About the “None” Scheduler?
Some AI clusters and high-frequency-trading rigs run none (aka noop) to shave every microsecond. But you’ll only see gains if your application handles queuing itself. For most of us, mq-deadline or BFQ is the sweet spot.
Bottom Line
If your week-old NVMe still feels like it’s on dial-up, check the scheduler first. Thirty seconds in the terminal can save you from a costly hardware “upgrade” that isn’t broken.
Run the test. Pick the winner. Enjoy the speed you already paid for.
