1 总体说明

Deadline调度器对一个请求的多方面特性进行权衡来进行调度,以期望既能满足块设备扇区的顺序访问又能兼顾到一个请求不会在队列中等待太久导致饿死。Deadline调度器为了兼顾这两个方面,通过红黑树来对请求按起始扇区序号进行排序,称为 sort_list ,通过 fifo 对请求按它们的生成时间进行排序,称为 fifo_list

batching - 每当确定了一个传输方向(读/写),那么将会从相应的 sort_list 中将一批连续请求 dispatchrequest_queue 的请求队列里,具体的数目由 fifo_batch(default-16) 来确定。

总体来讲,deadline算法对request进行了优先权控制调度,主要表现在如下几个方面:

  1. 读写请求分离,读请求具有高优先调度权,除非写请求即将被饿死的时候才会去调度写请求,这种处理可以保证读请求的延迟时间最小化;
  2. 对请求的顺序批量处理,对那些地址临近的顺序化请求,deadline给予了高优先级处理权。例如一个写请求得到调度后,其临近的request会在紧接着的调度过程中被处理,这种顺序批量处理的方法可以最大程度减少磁盘抖动;
  3. 保证每个请求的延迟时间。每个请求都赋予了一个最大延迟时间,如果达到延迟时间的上限,那么这个请求就会被提前处理,此时会破坏磁盘访问的顺序化而影响性能,但是保证了每个请求的最大延迟时间;

2 数据结构

struct deadline_data {
/*
* sort_list红黑树的根,用于对IO请求根据起始扇区进行排序
* 这里有两棵树,一棵读请求树,一棵写请求树
*/
struct rb_root sort_list[2];
/* 按照到期时间排列的先入先出队列FIFO */
struct list_head fifo_list[2]; /*
* 记录批量处理请求的下一个读/写请求
*/
struct request *next_rq[2];
/*
* 当前的发送数,当batching小于fifo_batch时,
* 请求会连续的发送,大于或等于16时就会启动下一轮dispatch
*/
unsigned int batching;
sector_t last_sector;
/* 写饥饿的次数 */
unsigned int starved; /*
* 这个数组分别存储了读/写请求的期限
* 读请求为500ms,写请求为5s
* 即使写请求超时也不一定立即得到相应,而是等到读请求当前的批次
* 大于写请求饥饿线的时候才去处理写请求
*/
int fifo_expire[2];
/* 批量发送的最大值 */
int fifo_batch;
/* 写请求饥饿线,默认为2 */
int writes_starved;
/* 表示能否进行前向合并的检查 */
int front_merges;
};

3 一般流程说明

3.1 请求到达

调用 deadline_add_request() 添加请求,代码执行流程如下:

static void
deadline_add_request(struct request_queue *q, struct request *rq)
{
struct deadline_data *dd = q->elevator->elevator_data;
/* 获取请求的方向,读还是写 */
const int data_dir = rq_data_dir(rq); /* 以请求的起始扇区为键值插入到红黑树中 */
deadline_add_rq_rb(dd, rq); /*
* 设置超时时间,这个请求在超时时间 jiffies + dd->fifo_expire[data_dir]
* 必须得到响应
*/
rq->fifo_time = jiffies + dd->fifo_expire[data_dir];
/* 将rq加入fifo_list */
list_add_tail(&rq->queuelist, &dd->fifo_list[data_dir]);
} static void
deadline_add_rq_rb(struct deadline_data *dd, struct request *rq)
{
/* 获取sort_list中指向根节点的指针root */
struct rb_root *root = deadline_rb_root(dd, rq); /* 将请求插入到红黑树中 */
elv_rb_add(root, rq);
}

3.2 入队完毕

调用 deadline_merge() 对请求进行合并,elevator会自己做后向合并,并且后向合并优先于前向合并

static int
deadline_merge(struct request_queue *q, struct request **req, struct bio *bio)
{
struct deadline_data *dd = q->elevator->elevator_data;
struct request *__rq;
int ret; /* 如果可以向前合并 */
if (dd->front_merges) {
sector_t sector = bio_end_sector(bio);
/* 如果能找到一个请求,它的起始扇区号和bio的结束扇区号相同即连续的 */
__rq = elv_rb_find(&dd->sort_list[bio_data_dir(bio)], sector);
if (__rq) {
BUG_ON(sector != blk_rq_pos(__rq));
/* 如果找到则进行合并 */
if (elv_bio_merge_ok(__rq, bio)) {
ret = ELEVATOR_FRONT_MERGE;
goto out;
}
}
} return ELEVATOR_NO_MERGE;
out:
*req = __rq;
return ret;
}

3.3 前向合并

如果做了前向合并,调用 deadline_merged_request() 进行处理,因为前向合并使得请求的起始扇区发生变化,所以相应的处理就是从 sort_list 中先删除再重新加回

static void deadline_merged_request(struct request_queue *q,
struct request *req, int type)
{
struct deadline_data *dd = q->elevator->elevator_data; /* 把合并了的请求从sort_list删除再加入 */
if (type == ELEVATOR_FRONT_MERGE) {
elv_rb_del(deadline_rb_root(dd, req), req);
deadline_add_rq_rb(dd, req);
}
}

3.4 合并后处理

合并后,调用 deadline_merged_requests() 做合并后的处理

static void
deadline_merged_requests(struct request_queue *q, struct request *req,
struct request *next)
{
if (!list_empty(&req->queuelist) && !list_empty(&next->queuelist)) {
/* 如果next的期限小于req */
if (time_before(next->fifo_time, req->fifo_time)) {
/* 这个queuelist实际上就是真正发给设备驱动程序的队列,处理完了的队列 */
list_move(&req->queuelist, &next->queuelist);
/* 因为是next比req要先响应,合并完了肯定要以先响应的为准 */
req->fifo_time = next->fifo_time;
}
} /* 从fifo_list和sort_list删除next */
deadline_remove_request(q, next);
}

3.5 派发

最后,调用 deadline_dispatch_requests() 将请求派发到系统的 request_queue 队列中

static int deadline_dispatch_requests(struct request_queue *q, int force)
{
struct deadline_data *dd = q->elevator->elevator_data;
const int reads = !list_empty(&dd->fifo_list[READ]);
const int writes = !list_empty(&dd->fifo_list[WRITE]);
struct request *rq;
int data_dir; /* 两个方向上的next_rq同时只能有一个为真 */
if (dd->next_rq[WRITE])
rq = dd->next_rq[WRITE];
else
rq = dd->next_rq[READ]; /* 如果有rq并且批量disaptch未到上限,则直接进行dispatch */
if (rq && dd->batching < dd->fifo_batch)
/* we have a next request are still entitled to batch */
goto dispatch_request; if (reads) {
BUG_ON(RB_EMPTY_ROOT(&dd->sort_list[READ]));
/* 触发写请求饥饿线,必须处理写请求了 */
if (writes && (dd->starved++ >= dd->writes_starved))
goto dispatch_writes; data_dir = READ; goto dispatch_find_request;
} if (writes) {
dispatch_writes:
BUG_ON(RB_EMPTY_ROOT(&dd->sort_list[WRITE]));
dd->starved = 0;
data_dir = WRITE;
goto dispatch_find_request;
} return 0; dispatch_find_request:
/*
* 我们不是处理批量请求,而是选择数据方向上最优的请求
*/ /*
* 如果fifo_list有超时或者下一个请求的方向变了,就去
* fifo_list去request,然后还得执行下面的dispatch_request
*/ /*
* 该请求方向存在即将饿死的请求,或不存在批量处理的请求,
* 则先从FIFO队列头取一个请求
*/
if (deadline_check_fifo(dd, data_dir) || !dd->next_rq[data_dir]) {
rq = rq_entry_fifo(dd->fifo_list[data_dir].next);
} else {
/*
* 为什么这里可以直接从fifo_list取而不是sort_list,因为
* 最终都需要通过rq的rb_node到sort_list找
*/
/* 按照扇区顺序处理请求 */
rq = dd->next_rq[data_dir];
} /* 启动新一批请求dispatch */
dd->batching = 0; dispatch_request:
/*
* rq is the selected appropriate request.
*/
dd->batching++;
/*
* 从fifo_list和sort_list中删除,再加入req->queuelist中,这里就从
* IO调度层离开了,移动一个请求到请求队列的派发队列
*/
deadline_move_request(dd, rq); return 1;
}

Linux Block模块之deadline调度算法代码解析的更多相关文章

  1. Linux Block模块之IO合并代码解析

    1 IO路径 从内核角度看,进程产生的IO路径主要有三条: 缓存IO:系统绝大部分IO走的这种形式,充分利用文件系统层的page cache所带来的优势.应用程序产生的IO经系统调用落入page ca ...

  2. linux内存管理--slab及其代码解析

    Linux内核使用了源自于 Solaris 的一种方法,但是这种方法在嵌入式系统中已经使用了很长时间了,它是将内存作为对象按照大小进行分配,被称为slab高速缓存. 内存管理的目标是提供一种方法,为实 ...

  3. Zepto.js库touch模块代码解析

    Zepto.js也许并不陌生,专门针对移动端开发,Zepto有一些基本的触摸事件可以用来做触摸屏交互(tap事件.swipe事件),Zepto是不支持IE浏览器的. 下面来解析一些Zepto.js触摸 ...

  4. alluxio源码解析-rpc调用概述-client和worker之间的block模块的通讯架构(netty版本)(3)

    (1.8版本)client和worker之间的block模块的通讯架构 block作为alluxio文件读取或者存储的最小基本单位,都是通过BlockOutStream和BlockInputtream ...

  5. Linux Cluster 基础之LVS调度算法与集群类型

    Linux Cluster 基础之LVS调度算法与集群类型 作者:尹正杰  版权声明:原创作品,谢绝转载!否则将追究法律责任. 一.LB Cluster 1>.什么是LB LB 集群是 load ...

  6. insmod模块加载过程代码分析1【转】

    转自:http://blog.chinaunix.net/uid-27717694-id-3966290.html 一.概述模块是作为ELF对象文件存放在文件系统中的,并通过执行insmod程序链接到 ...

  7. OpenStack之虚机热迁移代码解析

    OpenStack之虚机热迁移代码解析 话说虚机迁移分为冷迁移以及热迁移,所谓热迁移用度娘的话说即是:热迁移(Live Migration,又叫动态迁移.实时迁移),即虚机保存/恢复(Save/Res ...

  8. [nRF51822] 12、基础实验代码解析大全 · 实验19 - PWM

    一.PWM概述: PWM(Pulse Width Modulation):脉冲宽度调制技术,通过对一系列脉冲的宽度进行调制,来等效地获得所需要波形. PWM 的几个基本概念: 1) 占空比:占空比是指 ...

  9. 给linux安全模块LSM添加可链式调用模块(一)

    前些日子接了个外包的活,了解了一下Linux安全模块,发现了安全模块中的一些问题. 关于linux安全模块LSM在此就不多说了,大家google下就明白了. 这里主要介绍的是如何修改这个模块,使它可链 ...

随机推荐

  1. python第三方模块与内置模块

    目录 openpyxl模块 random随机模块 hashlib加密模块 subprocess模块 logging模块 openpyxl模块 1.读取:openpyxl不擅长读数据 所以有一些模块优化 ...

  2. MySQL Shell无法拉起MGR集群解决办法

    MySQL Shell无法拉起MGR集群解决办法 用MySQL Shell要重新拉起一个MGR集群时,可能会提示下面的错误信息: Dba.rebootClusterFromCompleteOutage ...

  3. Luogu5019 铺设道路 (贪心)

    水题,水得好无语 #include <iostream> #include <cstdio> #include <cstring> #include <alg ...

  4. java学习第一天.day06

    方法 方法的优点 1. 使程序变得更简短而清晰. 2. 有利于程序维护. 3. 可以提高程序开发的效率. 4. 提高了代码的重用性. static的作用 static在方法中如果没有添加就只能用对象调 ...

  5. 基于开源方案构建统一的文件在线预览与office协同编辑平台的架构与实现历程

    大家好,又见面了. 在构建业务系统的时候,经常会涉及到对附件的支持,继而又会引申出对附件在线预览.在线编辑.多人协同编辑等种种能力的诉求. 对于人力不是特别充裕.或者项目投入预期规划不是特别大的公司或 ...

  6. 从原理剖析带你理解Stream

    摘要:Stream是jdk1.8给我们提供的新特性 本文分享自华为云社区<深入理解Stream之原理剖析>,作者: 李哥技术 . Stream是jdk1.8给我们提供的新特性,主要就是允许 ...

  7. C++ 初识函数模板

    1. 前言 什么是函数模板? 理解什么是函数模板,须先搞清楚为什么需要函数模板. 如果现在有一个需求,要求编写一个求 2 个数字中最小数字的函数,这 2 个数字可以是 int类型,可以是 float ...

  8. kingbaseES R6 读写分离集群修改ssh端口案例

    数据库环境: test=# select version(); version ------------------------------------------------------------ ...

  9. 如何结合整洁架构和MVP模式提升前端开发体验(三) - 项目工程化配置、规范篇

    工程化配置 还是开发体验的问题,跟开发体验有关的项目配置无非就是使用 eslint.prettier.stylelint 统一代码风格. formatting and lint eslint.pret ...

  10. Git Bash(提交文件到GitHub进行托管)

    ​ Introduction 使用Git Bash命令,可以将一个项目上传到Github官网中,进行托管,避免重要文件被误删 1.Git工具下载 Git for Windows 2.在github中新 ...