I/O 调度：CFQ → mq-deadline → BFQ → kyber
内容提要
本文讨论了Linux I/O调度器的演变，特别是针对NVMe SSD的调度策略。传统调度器如CFQ和deadline因复杂性和对寻道优化的依赖逐渐被淘汰。现代调度器如none和kyber更适合NVMe，前者不进行调度，后者通过延迟反馈控制排队深度。文章强调调度器设计需适应硬件变化，简洁性更具长期价值。
关键要点
-
Linux I/O调度器的演变与NVMe SSD的调度策略密切相关。
-
传统调度器如CFQ和deadline因复杂性和对寻道优化的依赖逐渐被淘汰。
-
现代调度器如none和kyber更适合NVMe，前者不进行调度，后者通过延迟反馈控制排队深度。
-
调度器设计需适应硬件变化，简洁性更具长期价值。
-
CFQ在SSD普及后失效，因其核心假设（寻道昂贵）被否定。
-
deadline调度器通过简单的截止时间机制避免请求饿死，适应性广。
-
noop和none调度器在NVMe环境中表现优异，几乎无开销。
-
blk-mq架构的引入解决了单队列架构的性能瓶颈，提升了I/O性能。
-
mq-deadline是deadline调度器在blk-mq框架下的实现，适合HDD和SATA SSD。
-
BFQ调度器通过预算公平调度实现进程间公平性，适合中低速设备。
-
kyber调度器专为NVMe设计，采用延迟反馈控制排队深度，适合延迟敏感场景。
延伸解读
调度器的演变与硬件适配
Linux I/O调度器的演变反映了硬件技术的进步。CFQ等传统调度器在HDD时代因寻道时间长而设计复杂，但随着SSD的普及，这些假设失效，导致调度器的复杂性变得无关紧要。现代调度器如none和kyber则更简洁，适应了NVMe SSD的特性，强调了设计的简洁性在长期使用中的重要性。
选择合适的调度器
在选择I/O调度器时，需考虑设备类型和使用场景。对于NVMe SSD，none调度器在单租户环境中表现最佳，而在多租户或延迟敏感的场景中，BFQ或kyber更为合适。HDD则应使用mq-deadline以优化寻道性能。了解不同调度器的适用场景有助于提升系统性能。
调度器的性能与开销
不同调度器在性能和CPU开销上存在显著差异。BFQ在高IOPS场景下可能导致CPU成为瓶颈，而kyber在高负载下能有效控制延迟。选择调度器时，需权衡性能需求与系统资源，避免因调度器开销影响整体性能。
延伸问答
Linux I/O调度器的演变是怎样的？
Linux I/O调度器经历了从CFQ和deadline等传统调度器到现代调度器如none和kyber的演变，主要是为了适应NVMe SSD的特性。
CFQ调度器为何被淘汰？
CFQ因其复杂性、对寻道优化的依赖以及在SSD环境下的失效而被淘汰。
什么是mq-deadline调度器，它适用于哪些场景？
mq-deadline是deadline调度器在blk-mq框架下的实现，适用于HDD和SATA SSD，能够减少寻道时间并防止请求饿死。
kyber调度器的设计理念是什么？
kyber调度器的设计理念是通过延迟反馈控制排队深度，不进行请求排序或合并，专为NVMe设备优化。
BFQ调度器与CFQ调度器有什么不同？
BFQ调度器基于I/O预算进行调度，而CFQ调度器基于时间片，BFQ在公平性和交互检测上更为精确。
在什么情况下使用none调度器最优？
在NVMe SSD的单租户场景中，使用none调度器最优，因为它不引入额外的调度开销。
