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. windows下memcache安装

    Windows下的Memcache安装:1. 下载memcache的windows稳定版,解压放某个盘下面,比如在c:memcached2. 在终端(也即cmd命令界面)下输入 'c:memcache ...

  2. docker + Umami + Postgresql 网站访问分析

    1 # docker + Umami + Postgresql 2 # 官方安装文档:https://umami.is/docs/install 3 # 一.创建数据库 4 # 1.创建用户 5 CR ...

  3. 《吐血整理》进阶系列教程-拿捏Fiddler抓包教程(10)-Fiddler如何设置捕获Firefox浏览器的Https会话

    1.简介 经过上一篇对Fiddler的配置后,绝大多数的Https的会话,我们可以成功捕获抓取到,但是有些版本的Firefox浏览器仍然是捕获不到其的Https会话,需要我们更进一步的配置才能捕获到会 ...

  4. Spring源码 09 IOC refresh方法4

    参考源 https://www.bilibili.com/video/BV1tR4y1F75R?spm_id_from=333.337.search-card.all.click https://ww ...

  5. 搞定面试官 - 可以介绍一下在 MySQL 中你平时是怎么使用 COUNT() 的嘛?

    大家好,我是程序员啊粥. 相信在大家的工作中,有很多的功能都需要用到 count(*) 来统计表中的数据行数.同时,对于一些大数据的表,用 count 都是瑟瑟发抖,往往会结合缓存等进行处理. 那么, ...

  6. 透过inode来理解硬链接和软链接

    什么是inode? 每个文件都对应一个唯一的inode,inode用来存储文件的元信息,包括: 对应的文件 文件字节数 文件数据块的位置 文件的inode号码 文件的硬链接数 文件的读写权限 文件的时 ...

  7. ASP.Net Core异步编程

    ASP.Net Core异步编程 概念 什么是异步编程? 异步编程是可以让程序并行运行的一种手段,其可以让程序中的一个工作单元与主应用程序线程分开独立运行,并且在工作单元运行结束后,会通知主应用程序线 ...

  8. SpringBoot中如何使用自带的定时任务

    随便创建一个类,@Component交给spring管理,用注解@EnableScheduling,让定时任务生效 方法上加注解:@Scheduled(cron = "你的cron表达式&q ...

  9. day24--Java集合07

    Java集合07 14.HashMap底层机制 (k,v)是一个Node,实现了Map.Entry<K,V>,查看HashMap的源码可以看到 jdk7.0 的HashMap底层实现[数组 ...

  10. 并发与并行,同步和异步,Go lang1.18入门精炼教程,由白丁入鸿儒,Go lang并发编程之GoroutineEP13

    如果说Go lang是静态语言中的皇冠,那么,Goroutine就是并发编程方式中的钻石.Goroutine是Go语言设计体系中最核心的精华,它非常轻量,一个 Goroutine 只占几 KB,并且这 ...