deadline适合低延迟场景如数据库，cfq适合多任务公平调度；SSD应选mq-deadline或kyber，传统二者已逐步淘汰。
Linux IO调度器中，deadline 和 cfq（Completely Fair Queuing）是两种经典且差异明显的算法，适用于不同负载场景。选择哪个，关键看你的工作负载特征：是强调响应延迟（如数据库、交互式应用），还是追求公平带宽分配（如多用户桌面或虚拟机宿主）。
deadline：低延迟优先，适合随机读写密集型负载
deadline 调度器核心目标是**避免IO饥饿**和**控制最大延迟**。它为每个请求设置读/写截止时间（deadline），并维护三个队列：读队列、写队列、以及按截止时间排序的“到期队列”。当有请求临近超时，调度器会暂停当前顺序，优先服务该请求。
- 对机械硬盘（HDD）上的随机小IO（如MySQL的binlog写入、PostgreSQL的WAL日志）表现更稳定，延迟抖动小
- 不区分进程优先级，所有请求在截止时间约束下被一视同仁地调度
- 写操作默认延迟比读高（通常写 deadline 是读的5倍），可通过 /sys/block/sdX/queue/iosched/write_expire 调整
- 在SSD上效果常不如 noop 或 mq-deadline（现代内核已用 blk-mq 架构替代传统 CFQ/Deadline）
cfq：进程级公平调度，适合多任务、交互式环境
cfq 将IO请求按发起进程（或cgroup）分组，为每个组分配时间片和队列，在组间轮转调度，确保每个进程获得大致均等的磁盘带宽。它支持 I/O nice 值（ionice），允许用户手动调整进程IO优先级。
- 桌面系统、开发机或多用户服务器上体验更顺滑——一个后台rsync不会明显卡住前台浏览器
- 对顺序大IO（如视频转码、大文件拷贝）吞吐影响较小，但小IO延迟可能略高于deadline
- 默认启用“idle”模式（/sys/block/sdX/queue/iosched/idle），可进一步降低交互进程延迟，但会牺牲整体吞吐
- 在高并发容器/VM环境中，若未配合cgroup v2 + io.weight 控制，容易出现资源争抢失衡
怎么选？看实际场景
无需死记硬背理论，观察你系统的瓶颈点：
- 运行 PostgreSQL/MySQL 且 iostat -x 1 显示 %util 高、await 波动大 → 优先试 deadline
- 多用户共享服务器，或频繁切换前台/后台任务（如开发者主机）→ cfq 更友好
- 使用SSD或NVMe，且内核 ≥ 5.0 → 直接用 mq-deadline 或 kyber，传统 cfq/deadline 已被标记为遗留
- 做性能压测时，建议关闭电梯（echo none > /sys/block/sdX/queue/scheduler）排除调度干扰，再对比
验证与切换方法
临时切换（重启失效）：
echo deadline > /sys/block/sdX/queue/scheduler
echo cfq > /sys/block/sdX/queue/scheduler
永久生效需在内核启动参数（grub.cfg）中添加 elevator=deadline 或 elevator=cfq；现代发行版（如RHEL8+/Ubuntu 20.04+）默认使用 mq-deadline，cfq 已移除。
