---
title: "The Kyber I/O scheduler in Linux: what it does and when to use it"
url: "https://kyberlinux.com/blog/the-kyber-io-scheduler-in-linux"
description: "Kyber is a Linux block I/O scheduler built for fast SSDs and NVMe. How its latency targets work, how to switch to it and when mq-deadline, BFQ or none is the better choice."
---

# The Kyber I/O scheduler in Linux: what it does and when to use it

November 2, 2026·3 min read·Editorial team

A short multi-lane conveyor with small gates on each lane, letting a few parcels through at a time towards a single drive module

People who type “kyber linux” into a search engine are usually not looking for us. They are looking for Kyber, the block I/O scheduler that has been part of the Linux kernel since 2017. The name collision is a coincidence, so the least we can do is explain the thing they came for properly.

## What an I/O scheduler decides

Between a program asking to read a file and the disk returning the data sits the block layer. The scheduler is the part of it that decides in what order requests leave the queue for the device, and how many are allowed to be in flight at once.

On spinning disks that order mattered enormously, because the head had to move. On a modern NVMe drive with many hardware queues, reordering buys little. What still matters is fairness between kinds of work: a large background write should not make every small read wait behind it.

## How Kyber works

Kyber was written at Facebook for exactly that situation: fast multi-queue devices where the main risk is not seek time but a deep queue of slow requests delaying the fast ones.

It sorts requests into domains: reads, synchronous writes, discards and everything else. Each domain gets a number of tokens, and a request needs a token to be sent to the device. Kyber then measures how long requests actually take to complete. If reads are missing their latency target, it hands out fewer tokens to the other domains, so the device queue gets shorter and reads stop waiting behind writes. When latency is comfortably under target, it gives tokens back and throughput rises again.

That is the whole idea, and it is deliberately simple. There is no per-process accounting and no attempt to be fair between users. Kyber has two knobs and very little overhead per request, which is why it suits devices that handle hundreds of thousands of operations a second.

## Checking and switching the scheduler

The active scheduler is shown in square brackets:

```
cat /sys/block/nvme0n1/queue/scheduler
# [none] mq-deadline kyber bfq
```

If `kyber` is not listed, the module is not loaded:

```
sudo modprobe kyber-iosched
```

To switch a device at runtime:

```
echo kyber | sudo tee /sys/block/nvme0n1/queue/scheduler
```

The two latency targets live next to it, in nanoseconds. By default the read target is 2 ms and the synchronous write target is 10 ms:

```
cat /sys/block/nvme0n1/queue/iosched/read_lat_nsec
cat /sys/block/nvme0n1/queue/iosched/write_lat_nsec
```

A change made this way does not survive a reboot. To make it permanent, use a udev rule, for example in `/etc/udev/rules.d/60-iosched.rules`:

```
ACTION=="add|change", KERNEL=="nvme[0-9]*n[0-9]*", ATTR{queue/scheduler}="kyber"
```

## When Kyber is the right choice, and when it is not

**Kyber** fits fast SSDs and NVMe drives that serve mixed work, such as a database or a service that reads while something else writes in the background. Its job is to keep read latency predictable under load.

**none** is often the better default for a single very fast NVMe drive with one main workload. The device’s own queues do the work and any scheduler only adds overhead. Many distributions choose it for NVMe for this reason.

**mq-deadline** is the safe general choice for SATA SSDs and for hard disks. It gives every request a deadline, so nothing starves, and it behaves well on almost any device.

**BFQ** is for desktops and slow devices where interactivity matters more than throughput: a laptop copying a large file should still open a terminal instantly. It is the most capable of the four and the most expensive per request, which is why it is rarely used on servers with fast storage.

## How to decide without guessing

Measure the latency your users feel rather than the throughput a benchmark reports. Run your real workload, or a `fio` job that mixes reads with background writes, and compare the 99th percentile read latency under `none`, `mq-deadline` and `kyber`. If the tail does not move, keep the simplest option. If background writes are visibly hurting reads on a fast drive, Kyber is the tool built for that problem.

## And KyberLinux?

KyberLinux is a different thing that shares the first half of the name: an ultralight, secure, open-source operating system for SI, the same on a pocket deck, a robot and a cloud node. If that is what you were looking for after all, [start here](https://kyberlinux.com/).

-   kyber
-   io scheduler
-   linux kernel
-   nvme
-   latency

## Keep reading

-   [Agent factories will leave IT for machines nobody runs](https://kyberlinux.com/blog/agent-factories-on-machines-nobody-runs)
-   [A reference list without Debian: choosing a base for SI](https://kyberlinux.com/blog/a-reference-list-without-debian)