一、调度器演进
1.1 什么是IO调度器？
传统的磁盘因为有磁头，磁头移动有开销。最早的调度器会对访问磁盘的IO做基于磁盘访问位置的排序和合并， 让磁头以最少的移动来完成最大的IO量， 以提升系统IO带宽。
现在的SSD， 物理上已没有磁头的概念， 访问的位置也是LBA（Logical block address）， 器件内部负责找到LBA到物理位置的映射关系。排序就没有太大作用， 随机访问的速度也接近顺序读写。IO调度主要是以服务应用场景为主（读优先，VIP线程优先，时间片/带宽公平调度等） 。
IO scheduler处于内核IO栈 中block layer的一部分，主要作用就是对IO 进行qos, 根据不同的qos目标（延迟、公平、带宽、功耗等）有各种各样的调度器：历史到现在mainline出现过（红色是现存的）：noop(只做简单的merge )/deadline(排序，读写区分对待，延迟控制)/cfs(时间片公平)/mq-deadline/bfq(带宽公平)/kyber(不同的IO类型 q不同的延迟)
未进mainline的调度器：
SIO(不合并IO)、VR（翻转磁头惩罚机制）、Row（read over write）、Zen（不合并也不排序,仅有超期处理） 、Maple（不合并不排序，亮屏和灭屏策略不一样） 、FIO(基于IOPS指标 进程公平)等。
这些调度器随着发展， 目前只有右图这样子：
现在看看这些调度器的策略有什么不同：
1.2 kernel 6.1 社区调度器
Kyber调度器
2017年引入，2018后就不怎么修改(目前为止，没有支持io priority /blk cg)。核心思想， 就是把IO分成不同的类型（读、写、擦除、其他）， 每个类型的队列单独控制延时， q的是不同的延迟， 所有策略围绕这个目标展开。
默认情况下延迟控制如上
1.3 MQ-DEADILINE调度器
作为deadline的mult queue版本。deadline在内核2.5时代已经存在。
核心思想没有变化：
1. IO进入调度器会被同时加入 读写rb tree 和fifo 队列中， 按访问sector排序。
2. 如果有超期的IO ，先发送超期的IO， 无超期的IO 按优先级发送IO， 同优先级读写非严格按照2:1 dispatch, 发送IO时 按各自rb tree 发送（sector 增长方向）。
3. 读和写的超期时间不一样。 
4. 预留了1/4 req给同步IO(除去write)。
5. dispatch先检查超期req (读和写超期时间不一样), 无超期 再按读写2:1的比例下发IO。
6. linux-5.14开始支持ioclass/ionice。
7. 不支持blk cgroup
1.4 BFQ调度器
改自CFQ，BFQ 是 带宽公平的调度器， 支持cgroup. 从4.12版本开始支持, 设计原则想兼顾带宽和响应。实际上由于算法复杂，最低lat会其他调度器多数倍。
核心特性：
1. “budget fair”策略：每个线程公平的分配sector数进行IO， 因交互式进程只需少量的budget, 交互式进程得以快速响应。
2. 优先级支持：进程bfq weight越大（新进程权重临时提升），budget增长越慢（意味着调度更频繁）。
3. 调度效率。引入idle_time，做完一个thread的IO后 。为了不让这个APP后续IO重新排队（也为了新的APP得到比较好速度）， 会idle一定时间再切换下一个线程。
二、kernel6.1的elv(bfq/kyber/mq-deadline)
elv 实现其实是一套call back 嵌入在block layer, 搞清楚这些call back就可以看出不同elv的核心思想。
一笔IO 要在elv中经过：allow_megre->bio_merge->requset_merge->request_merged->limit_depth->prepare_request->insert_request->has_work->dispatch_request->completed_request->finish_request 才可以一笔IO。
在block layer， 什么时候IO 会进入调度器？
实际上有很多入口，整体上submit_bio是从fs下来的普通IO（常规的文件访问），其他一些入口主要给一些特别的IO使用，比如ioctl（查询器件状态等）, flush等。这些特别的IO 虽然会经历这个flow，但通常by pass调度器。
insert req就是把req挂入到elv的队列中（每种elv的队列实现方式通常都不一样）， dispatch的线程不一定是IO的发起者， 有两个case:
1. IO业务发起者直接下发到设备驱动，（需要同步IO + 设备ready)
2. 经过run_work异步线程转发(异步IO，或同步IO发起时，设备没ready)
2.1 Kyber调度器
Kyber引入调度域的概念：给IO划分了4个调度域，每个域都有一个bitmap, 表示该域req 资源占用情况。
每个调度域的深度不一样, 即可用req数量不一样。插入IO实际上就是插入到这个阈所属的队列上。
每个调度域batch size不一样，即每次一个调度域单次最多dispatch处理batch_size个reqs。
异步IO 占比75%， 即总是预留25% 的req给同步IO。
不同类型IO延迟控制不一样。
Kyber insert req
可以看到就是根据IO的类型， 比如是读 还是写 或擦除操作，把IO加入到不同阈的队列当中。
Kyber dispatch
Dispatch则是根据不同阈IO的质量（kyber以IO花费的平均时间作为指标,），选择合适的队列进行dispatch
选择一个domain 最多发送batch个req.
找到队列中的req进行dispatch
kyber在选择domain时，要根据IO的质量(IO花费时间)， 下面说说质量是如何算的：
Kyber 时延计算
KYBER_IO_LATENCY: rq执行的时间（类似D2C）
KYBER_TOTAL_LATENCY：rq从申请出来到执行完的时间（类似G2C）
简单的可以理解为，kyber在IO完成的时候，根据IO的花费时间，在bucket中选择合适的位置进行计数。 比如1 为延迟10ms, 如果这笔IO完成在3/4 * 10ms -> 10ms之间， 则在1的bucket里+1；
这样定期查看下某个类型的buckets 比如READ domian， 就可以看到99% READ 延迟在哪个区段。如果落在1之内认为IO是好的， 如果都大于1 认为IO是坏的。
如果IO是坏的，那以后就多发这个类型的IO，少发其他类型的IO， 这类型IO的延迟就可能会好转。Kyber就是通过调整发不同类型IO的数量来完成IO的时延控制。
看下他是如何调整分发数量的：
Kyber 根据时延调整 队列深度
good_buckets即上述所指1的位置, 计算99%的IO和90%的IO在什么区段，来调整队列的depth
如果比较差，就增加对应队列一倍的depth. 如果很好就缩减到3/4的深度。
延迟的计算如下
Kyber小结
2.2 mq_deadline调度器
从数据结构来看， 他有优先级的概念，并且有所谓的方向（读or写）
struct deadline_data *dd = q->elevator->elevator_data;
同时也有expire的概念。
从数据上看， 总结为：
mq_deadline 三个优先级，两种队列，两种IO类型
mq_deadline 插入req, 就是根据IO是读写， 把IO插入到对应优先级的双重队列里：即插入到fifo队列 和sort队列（根据IO访问磁盘的位置）中
mq_deadline insert req
分发条件也简单， 统计进入elv的总数，有IO 就可以发
mq_deadline has work
所谓的deadline，即IO进入elv开始到dispatch有一个deadline.
因此在发送顺序上， 要先找超期的req进行发送， 如果没有超期的req，则按优先级进行发送。
mq_deadline dispatch
mq_deadline 小结
IO 按磁盘位置在对应优先级的sort tree上排序，发送时先发超期IO，再按优先级发送。（实际上还有write_starved的概念，deadline倾向于发读IO，为了防止写饿死， 会发write_starved次读，才会发一次写）
2.3 BFQ(Budget Fair Queueing)调度器
BFQ的核心思想，就是by thread的发送IO，有点CPU 调度的味道, 每次能发的最大IO量即所谓的Budget。BFQ想保证不同的thread在IO量上是“公平的”。
整体思想就是每个thread在IO上也有一个vtime， 每次总是选vtime小的thread进行发送IO。对于IO的vtime的增长， 在BFQ上是根据这个线程发过的IO量*系数来决定的， 每次能发的最大虚拟IO量 即所谓的buget。
而这里的系数，则比较复杂，BFQ会根据不同类型的IO负载 ，给thread打上标签，比如是交互式线程 还是IO消耗性线程，甚至是刚起来的新线程，依赖多个维度权衡去动态调整系数。从而保证整个系统有比较好的IO响应且比较好的带宽。
由于BFQ的细节流程比较复杂，这里列出其flow:
BFQ insert req
BFQ dispatch req
BFQ dispatch req
总是选vtime最小的进行发送
三、cgroup/ionice
有些调度器是支持IO优先级和cgroup的，业务方时间上可以根据这两个机制 来调整自己IO的质量。
usage: ionice [-t] [-c CLASS] [-n LEVEL] [COMMAND...|-p PID]
deadline idle/RT的带宽差距
两个cgroup: target为idle， load为RT
cgroup
example:
v1：echo 100 > /dev/blkio/target/blkio.bfq.weight
v2：echo "8:16 rbps=2097152 wiops=120" > io.max
四、other vendor elv
https://github.com/codediablos/io-scheduler/blob/master/vr-iosched.c
https://github.com/codediablos/io-scheduler/blob/master/sio-iosched.c
https://github.com/Pzqqt/android_kernel_xiaomi_whyred/blob/5e5993a2fa5c19d29fe63ee628299ff97ba910fd/block/fiops-iosched.c
https://github.com/codediablos/io-scheduler/blob/master/row-iosched.c
https://github.com/Pzqqt/android_kernel_xiaomi_whyred/blob/5e5993a2fa5c19d29fe63ee628299ff97ba910fd/block/maple-iosched.c#L4
https://github.com/codediablos/io-scheduler/blob/master/zen-iosched.c
参考资料：
1.https://elixir.bootlin.com/linux/v6.1.80/source/Documentation/block
2.BFQ:
https://blog.csdn.net/hu1610552336/article/details/125862606
往
期
推
荐
Perfetto数据流架构故障分析：带你研究 trace 为何丢失
长按关注内核工匠微信
Linux内核黑科技| 技术文章| 精选教程
扫一扫
9173
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
