Linux内核学习轨迹第七部：IO调度器（第五节）

5. IO调度器全解析：none/mq-deadline/kyber/bfq

IO调度器是Linux块层的核心组件，位于blk-mq软件队列与硬件队列之间，是IO性能调优的核心抓手。它的核心职责是对上层下发的IO请求做合并、排序、优先级调度、公平性控制，解决两大核心问题：一是减少机械硬盘的磁头寻道开销，最大化吞吐量；二是控制IO延迟、解决IO饥饿、保证业务的服务质量。

Linux 6.0内核完全移除了传统单队列架构的调度器（cfq、传统deadline、noop），仅保留适配blk-mq多队列架构的调度器。本章节基于Linux 6.6 LTS内核，完整拆解生产环境主流的4个调度器：none（原noop）、mq-deadline、kyber、bfq，包括设计思想、核心实现、适用场景、调优方案与避坑指南。

---

5.1 IO调度器的核心设计目标

所有IO调度器都围绕以下核心目标设计，不同调度器在不同目标上做了取舍：

1. 最大化吞吐量：通过IO合并、扇区排序，减少机械硬盘的磁头寻道次数，提升磁盘的有效IO吞吐量；
2. 控制IO延迟：保证同步IO、关键业务IO的低延迟，避免长尾延迟恶化；
3. 解决IO饥饿：避免某一类IO（如随机读）被另一类IO（如大块顺序写）长时间阻塞，导致请求饿死；
4. 保证公平性：在多进程/多租户场景下，保证每个进程/租户能公平占用IO资源，避免单个进程占用所有IO带宽；
5. 适配硬件特性：针对机械硬盘、SSD、NVMe等不同存储硬件的特性，做针对性的优化，最小化CPU开销。

---

5.2 主流IO调度器深度拆解

5.2.1 none调度器（原noop调度器）

none调度器是blk-mq架构下的无操作调度器，对应传统单队列架构的noop调度器，是Linux 6.6内核NVMe设备的默认调度器。

核心设计思想

none是最简单的调度器，不做任何IO排序、优先级调度、延迟控制，仅做最基础的前后IO合并，完全按照FIFO（先进先出）的顺序把请求下发给驱动。它的核心设计逻辑是：现代NVMe SSD内部的FTL（闪存转换层）已经实现了高级的IO调度、磨损均衡、垃圾回收，内核层的排序调度只会带来额外的CPU开销，没有任何性能收益。

核心实现原理

none调度器的源码实现极简，核心逻辑只有两点：

1. IO合并：新请求入队时，仅尝试和队列中已有的请求做前向/后向合并，不做任何排序；
2. FIFO下发：请求入队后，直接加入到硬件队列的分发链表，按照入队顺序下发给驱动，没有任何调度逻辑。

核心特性与适用场景

• 优势：CPU开销极低，完全无锁调度，最大化发挥NVMe多队列硬件的并行能力，随机IO场景下IOPS最高、延迟最低；
• 劣势：无任何公平性、延迟控制、饥饿保护机制，机械硬盘场景下吞吐量极差，多进程大流量顺序写会导致读请求严重饥饿；
• 最佳适用场景：所有NVMe SSD/企业级SSD场景、随机IO为主的业务（数据库、KV存储、高频交易）、多核多队列硬件环境。

---

5.2.2 mq-deadline调度器

mq-deadline是传统单队列deadline调度器的blk-mq适配版，是机械硬盘HDD的默认调度器，也是生产环境HDD场景的首选。

核心设计思想

mq-deadline的核心目标是解决IO饥饿问题，同时最大化机械硬盘的吞吐量。它给每个IO请求设置一个「截止时间」，保证请求不会被长时间饿死，同时通过扇区排序减少磁头寻道开销。针对读写的业务特性做了差异化设计：读请求通常是同步阻塞的，对延迟更敏感，因此读的截止时间更短，优先级更高；写请求通常是异步的，对延迟不敏感，截止时间更长。

核心实现原理

mq-deadline的核心是4个独立的队列+双逻辑：

1.4个核心队列：

• 读排序队列：按IO请求的起始扇区升序排序，用于减少磁头寻道，提升吞吐量；
• 读截止队列：按IO请求的截止时间升序排序，用于保证读请求不会饿死；
• 写排序队列：同读排序队列，用于写请求的扇区排序；
• 写截止队列：同读截止队列，用于写请求的饥饿保护。

2.截止时间默认配置（可通过sysfs调整）：

• 读请求截止时间：500ms；
• 写请求截止时间：5000ms；
• 写饥饿阈值：当连续处理了16个写请求后，必须处理一次读请求，避免读请求被饿死。

3.核心调度逻辑：

1. 新请求入队时，同时加入排序队列和截止队列，设置对应的截止时间；
2. 调度器优先从排序队列取请求，最大化吞吐量；
3. 每次调度前，先检查截止队列中是否有超时的请求，如果有，优先处理超时的请求，保证不会饿死；
4. 当连续处理的写请求达到阈值后，强制切换到读队列处理，保证读请求的优先级。

核心特性与适用场景

• 优势：完美适配机械硬盘的物理特性，吞吐量最高，同时有效解决IO饥饿问题，保证读请求的低延迟，稳定性极强，20+年生产环境验证；
• 劣势：对NVMe SSD优化不足，有一定的CPU开销，无公平性保证，多租户场景下无法隔离IO资源；
• 最佳适用场景：所有机械硬盘HDD/RAID阵列场景、顺序读写为主的业务（大数据、视频存储、日志服务）、混合读写的通用服务器场景。

---

5.2.3 kyber调度器

kyber是Facebook为NVMe SSD低延迟场景设计的blk-mq专属调度器，在Meta的大规模数据中心经过了生产验证，是低延迟业务场景的首选。

核心设计思想

kyber的核心目标是控制NVMe SSD的IO长尾延迟，保证同步IO的低延迟和可预测性。它完全摒弃了传统的扇区排序逻辑，基于令牌桶算法+多队列深度限制实现调度，核心逻辑是：限制同步读、同步写的最大队列深度，避免IO请求在硬件队列中排队导致延迟升高，同时异步写不做限制，最大化后台写入的吞吐量。

核心实现原理

kyber的核心是双令牌桶+动态调优：

1.两个核心令牌桶：

• 同步读令牌桶：默认令牌数128，同步读请求必须拿到令牌才能入队下发；
• 同步写令牌桶：默认令牌数32，同步写请求必须拿到令牌才能入队下发；
• 异步写（脏页回写）：无令牌限制，直接下发，不占用同步IO的令牌资源。

2.动态调优逻辑：

调度器会实时统计IO的平均延迟和长尾延迟，动态调整两个令牌桶的大小：如果延迟升高，就减少令牌数，降低队列深度，减少排队延迟；如果延迟低于阈值，就增加令牌数，最大化IOPS。

3.调度优先级：同步读 > 同步写 > 异步写/丢弃/刷新请求，严格保证业务同步IO的优先级，避免后台异步写抢占IO资源。

核心特性与适用场景

• 优势：专为NVMe SSD设计，CPU开销极低，完美控制99.9%长尾延迟，同步IO的延迟可预测性极强，适配高并发低延迟的业务场景；
• 劣势：机械硬盘场景完全不适用，无排序逻辑，吞吐量极差；无公平性保证，多租户场景无法隔离IO资源；
• 最佳适用场景：NVMe SSD低延迟场景、数据库/分布式KV存储、高频交易、在线业务等对长尾延迟敏感的场景。

---

5.2.4 bfq调度器

bfq（Budget Fair Queueing，预算公平队列）是传统单队列cfq调度器的blk-mq升级版，专为桌面/嵌入式/多租户场景设计，核心目标是保证IO资源的完全公平分配，同时优化交互场景的低延迟。

核心设计思想

bfq的核心是基于权重的完全公平调度，它给每个进程/线程分配一个独立的IO队列，按照进程的权重分配「IO预算」（默认按时间分配，也可按扇区数分配），进程用完预算后，调度器切换到下一个进程的队列，保证所有进程按权重公平占用IO资源。同时对前台交互进程、实时进程做优先级提升，大幅降低桌面场景的应用启动延迟、操作卡顿。

核心实现原理

bfq的核心是独立进程队列+预算分配+优先级提升：

1.Per-Process独立队列：每个进程对应一个独立的IO队列，进程的IO请求只会进入自己的队列，完全隔离，避免不同进程的IO相互干扰；

2.预算分配机制：

• 每个进程默认权重相同，分配相同的IO预算；
• 可以通过ionice工具调整进程的IO优先级和权重，高权重进程分配更多的预算；
• 调度器按照预算比例，给每个队列分配执行时间，预算用完立即切换队列，保证完全公平；

3.交互场景优化：

• 自动识别前台交互进程、应用启动进程，临时提升其IO优先级和预算，让应用启动更快、操作更流畅；
• 对后台批量写进程降低优先级，避免后台任务占用IO资源导致前台卡顿；

4.低延迟模式：针对SSD场景优化的低延迟模式，减少预算切换的开销，保证低延迟的同时兼顾公平性。

5.核心特性与适用场景

• 优势：完美的IO公平性，多进程/多租户场景下IO资源隔离效果极佳，桌面交互场景延迟极低，体验流畅，支持精细化的IO优先级控制；
• 劣势：CPU开销较高，高并发IO场景下吞吐量不如none/kyber，机械硬盘大吞吐量场景不如mq-deadline；
• 最佳适用场景：桌面Linux发行版、安卓/嵌入式系统、多租户容器/虚拟机场景、需要精细化IO优先级控制的场景。

5.3 四大调度器核心对比与选型指南

特性维度	none（noop）	mq-deadline	kyber	bfq
核心设计	无调度，仅合并，FIFO下发	截止时间保护+扇区排序，防饥饿+高吞吐	令牌桶+队列深度控制，NVMe低延迟	按进程权重公平分配，保证隔离性
IO排序	无	按扇区升序排序	无	可选排序
延迟优化	无额外延迟，原生硬件延迟	优化读请求延迟，防饥饿	极致优化99.9%长尾延迟	优化前台交互进程延迟
公平性保证	无	无	无	完全公平，按权重分配
CPU开销	极低	低	极低	中高
适配硬件	NVMe SSD/企业级SSD	机械硬盘HDD/RAID阵列	NVMe SSD低延迟场景	桌面/嵌入式/多租户场景
典型业务场景	数据库、KV存储、高频交易、通用NVMe场景	大数据、日志存储、HDD通用服务器	在线业务、低延迟交易、分布式存储	桌面Linux、安卓、容器多租户

生产环境选型最佳实践

1.NVMe SSD场景：

• 绝大多数通用场景、随机IO为主的业务：优先选none，CPU开销最低，IOPS最高；
• 对99.9%长尾延迟敏感的在线业务、数据库：优先选kyber，延迟可预测性更强；
• 多租户容器/虚拟机场景：选bfq，保证IO资源公平隔离。

2.机械硬盘HDD/RAID阵列场景：

• 所有通用场景、顺序读写为主的业务：必须选mq-deadline，吞吐量最高，防饥饿效果最好；
• 桌面/嵌入式HDD场景：选bfq，保证交互流畅度。

3.SATA/SAS SSD场景：

• 企业级SSD：选none/kyber；
• 消费级SSD：选mq-deadline，消费级SSD的FTL能力较弱，内核排序能提升一定性能。

---

5.4 IO调度器的配置与调优

5.4.1 调度器的查看与临时配置

1.查看当前设备的调度器：

# 查看sda设备的调度器，中括号标记的是当前生效的调度器
cat /sys/block/sda/queue/scheduler
# 查看所有块设备的调度器
for dev in $(ls /sys/block/ | grep -E 'sd|nvme|hd'); 
do echo 
    "$dev: $(cat /sys/block/$dev/queue/scheduler)"; 
done

2.临时修改调度器（重启失效）：

# 把nvme0n1设备的调度器设置为kyber
echo kyber > /sys/block/nvme0n1/queue/scheduler
# 把sda设备的调度器设置为mq-deadline
echo mq-deadline > /sys/block/sda/queue/scheduler

3.永久配置调度器：

• 方式1：通过udev规则配置，编辑/etc/udev/rules.d/60-io-scheduler.rules：

# NVMe设备默认使用kyber调度器
ACTION=="add|change", KERNEL=="nvme*n1", ATTR{queue/scheduler}="kyber"
# SATA/SAS HDD设备默认使用mq-deadline调度器
ACTION=="add|change", KERNEL=="sd*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="mq-deadline"
# SATA SSD设备默认使用none调度器
ACTION=="add|change", KERNEL=="sd*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"

• 方式2：通过内核启动参数配置，在grub的GRUB_CMDLINE_LINUX中添加：

elevator=mq-deadline

执行update-grub重启生效，该配置会设置所有设备的默认调度器。

5.4.2 各调度器的核心调优参数

所有调度器的调优参数都在/sys/block/[设备名]/queue/iosched/目录下，针对不同调度器有不同的可调参数。

1.mq-deadline调度器调优参数：

参数	核心含义	默认值	调优建议
read_expire	读请求的截止时间，单位毫秒	500	读延迟敏感场景调小到200；顺序读大文件场景调大到1000
write_expire	写请求的截止时间，单位毫秒	5000	写敏感场景调小到1000；日志写入场景调大到10000
writes_starved	连续处理多少个写请求后，强制处理读请求	16	读优先场景调小到8；写优先场景调大到32
front_merges	是否开启前向合并	1	随机IO场景关闭（设为0），减少CPU开销；顺序IO场景开启

2.kyber调度器调优参数：

参数	核心含义	默认值	调优建议
read_lat_nsec	读请求的目标延迟，单位纳秒	2000000（2ms）	低延迟场景调小到1000000（1ms）；高IOPS场景调大到5000000（5ms）
write_lat_nsec	写请求的目标延迟，单位纳秒	10000000（10ms）	同步写敏感场景调小到2000000（2ms）；异步写场景调大到20000000（20ms）

3.bfq调度器调优参数：

参数	核心含义	默认值	调优建议
low_latency	低延迟模式开关	1（开启）	桌面场景保持开启；高吞吐量服务器场景关闭（设为0）
timeout_sync	同步进程的最大预算时间，单位毫秒	124	桌面场景调大到200，提升前台进程性能；服务器场景调小到50，提升公平性
max_budget	单个进程的最大IO预算，单位扇区数	0（自动计算）	大文件顺序写场景调大到2048；小文件随机IO场景调小到512

5.5 工程实践避坑指南

1.NVMe SSD不要用mq-deadline调度器：

很多老教程会推荐NVMe用deadline调度器，这是完全错误的。现代NVMe SSD的FTL已经实现了高级的IO调度，内核层的排序只会带来额外的CPU开销，不会提升性能，反而会导致延迟升高。NVMe场景优先用none或kyber。

2.不要混用单队列和多队列调度器：

Linux 6.0之后，传统单队列的cfq、deadline、noop已经被完全移除，很多老教程的配置已经失效，强行配置会导致调度器不生效，回退到none调度器。生产环境必须使用blk-mq原生的4个调度器。

3.调度器选型要匹配硬件，不要一刀切：

不要给所有设备都配置同一个调度器，机械硬盘用mq-deadline，NVMe用none/kyber，桌面场景用bfq，必须根据硬件和业务场景做差异化配置，否则会导致性能严重下降。

4.ionice优先级仅对bfq调度器生效：

ionice工具设置的IO优先级，仅在bfq调度器下生效，其他调度器会忽略优先级配置。很多人误以为设置了ionice就会生效，却不知道调度器不支持，导致优先级配置完全无效。

5.不要随意调大截止时间和队列深度：

很多人为了提升吞吐量，盲目调大mq-deadline的截止时间、kyber的令牌数，会导致IO排队延迟急剧升高，99.9%长尾延迟恶化10倍以上，尤其是在线业务场景，必须优先保证延迟，再追求吞吐量。