Linux noop io 调度算法分析

定义了一个elevator_noop的调度器类型:

static struct elevator_type elevator_noop = {
	.ops = {
		.elevator_merge_req_fn		= noop_merged_requests,//查询一个request,用于将bio并入
		.elevator_dispatch_fn		= noop_dispatch,//将noop调度器链表中最前面的请求取出,分派给块设备的请求队列
		.elevator_add_req_fn		= noop_add_request,//将一个新request加入noop调度器链表的尾部
		.elevator_queue_empty_fn	= noop_queue_empty,//判断noop调度器链表中是否存在请求
		.elevator_former_req_fn		= noop_former_request,//在noop调度器链表中,获取指定请求的前一个请求
		.elevator_latter_req_fn		= noop_latter_request,//在noop调度器链表中,获取指定请求的后一个请求
		.elevator_init_fn		= noop_init_queue,
		.elevator_exit_fn		= noop_exit_queue,
	},
	.elevator_name = "noop",
	.elevator_owner = THIS_MODULE,
};

定义了一个管理noop调度器的数据结构:

struct noop_data {
	struct list_head queue;
};

只有一个成员queue,其实就是noop中维护的一个fifo(先进先出)链表的链表头,当io请求过来了,就会被加入到这个链表的尾部。

在链表前面的才会被移到块设备的请求队列(request_queue)中。我们来看看关键的两个函数。

static void noop_add_request(struct request_queue *q, struct request *rq)
{
struct noop_data *nd = q->elevator->elevator_data;
list_add_tail(&rq->queuelist, &nd->queue);
}

看到了list_add_tail了吧,这里就将请求加入到链表的尾部。

再来看看请求是如何从noop调度器的fifo链表移动到块设备的请求队列(request_queue)中的

static int noop_dispatch(struct request_queue *q, int force)
{
 struct noop_data *nd = q->elevator->elevator_data;

 if (!list_empty(&nd->queue)) //调度器链表中有请求
 {
  struct request *rq;
  rq = list_entry(nd->queue.next, struct request, queuelist);//获取调度器链表中的第一个请求
  list_del_init(&rq->queuelist);//将该请求从调度器链表中删除
  /*
  将该请求发往块设备的请求队列request_queue
  并通过request需要访问的起始地址,将该请求插入到块设备请求队列的适当位置
  */
  elv_dispatch_sort(q, rq);
  return 1;
 }
 return 0;
}

同样很简单 rq =
list_entry(nd->queue.next, struct request, queuelist);

这个list_entry宏是根据当前的链表节点找到对应的对象。其实质是container_of()宏,内核中大量使用这个宏,可以说它是内核的基础。

如果你之前接触过驱动,那么对这个宏肯定不陌生。

这个对象的类型是由第二参数决定的,这个节点在对象结构体中的名字是由第三个参数决定的,那么第一个参数就是要处理的节点了。

为什么是queue.next呢?因为queue是头(head),它的下一个(next)才是链表的第一个节点(node)。

list_del_init(&rq->queuelist);

将刚才找到的节点(node)从链表中删掉,为什么呢?因为这个即将进入块设备的request_queue,得让第二节点变成第一个,否则后面的请求就永无翻身之日了。

elv_dispatch_sort(q, rq);

相信大家已经知道这个函数是将刚才取出的第一个rq放入到块设备的请求队列(request_queue)中。

好了,noop就是这么简单。

附:2.6.32版本下noop的完整代码加注释

struct noop_data {
	struct list_head queue;
};

//将合并后多余的那个请求给删除
static void noop_merged_requests(struct request_queue *q, struct request *rq,
				 struct request *next)
{
	list_del_init(&next->queuelist);
}

//将noop调度器中首结点对应的请求发往块设备的请求队列request_queue
static int noop_dispatch(struct request_queue *q, int force)
{
	struct noop_data *nd = q->elevator->elevator_data;

	if (!list_empty(&nd->queue)) {//调度器链表中有请求
		struct request *rq;
		rq = list_entry(nd->queue.next, struct request, queuelist);//获取调度器链表中的第一个请求
		list_del_init(&rq->queuelist);//将该请求从调度器链表中删除
		/*
		将该请求发往块设备的请求队列request_queue
		并通过request需要访问的起始地址,将该请求插入到块设备请求队列的适当位置
		*/
		elv_dispatch_sort(q, rq);
		return 1;
	}
	return 0;
}

//将请求加入调度器链表的尾部
static void noop_add_request(struct request_queue *q, struct request *rq)
{
	struct noop_data *nd = q->elevator->elevator_data;

	list_add_tail(&rq->queuelist, &nd->queue);
}

//判断调度器链表中是否没有请求
static int noop_queue_empty(struct request_queue *q)
{
	struct noop_data *nd = q->elevator->elevator_data;

	return list_empty(&nd->queue);
}

//在调度器链表中,获取请求rq的前一个请求
static struct request *
noop_former_request(struct request_queue *q, struct request *rq)
{
	struct noop_data *nd = q->elevator->elevator_data;

	if (rq->queuelist.prev == &nd->queue)//如果该请求rq已经是第一个请求,则返回NULL
		return NULL;
	/*
	通过内嵌的双向链表结构获取request的地址
	该list_head结点的起始地址 + list_head成员在request结构中的偏移地址 = request的起始地址
	*/
	return list_entry(rq->queuelist.prev, struct request, queuelist);
}

//在调度器链表中,获取请求rq的下一个请求
static struct request *
noop_latter_request(struct request_queue *q, struct request *rq)
{
	struct noop_data *nd = q->elevator->elevator_data;

	if (rq->queuelist.next == &nd->queue)
		return NULL;
	return list_entry(rq->queuelist.next, struct request, queuelist);
}

static void *noop_init_queue(struct request_queue *q)
{
	struct noop_data *nd;

	nd = kmalloc_node(sizeof(*nd), GFP_KERNEL, q->node);
	if (!nd)
		return NULL;
	INIT_LIST_HEAD(&nd->queue);
	return nd;
}

static void noop_exit_queue(struct elevator_queue *e)
{
	struct noop_data *nd = e->elevator_data;

	BUG_ON(!list_empty(&nd->queue));
	kfree(nd);
}

static struct elevator_type elevator_noop = {
	.ops = {
		.elevator_merge_req_fn		= noop_merged_requests,//查询一个request,用于将bio并入
		.elevator_dispatch_fn		= noop_dispatch,//将调度器的链表中最前面的元素取出,分派给块设备的请求队列
		.elevator_add_req_fn		= noop_add_request,//将一个新request加入noop调度器链表的尾部
		.elevator_queue_empty_fn	= noop_queue_empty,//判断noop调度器链表中是否存在请求
		.elevator_former_req_fn		= noop_former_request,//在noop调度器链表中,获取指定请求的前一个请求
		.elevator_latter_req_fn		= noop_latter_request,//在noop调度器链表中,获取指定请求的后一个请求
		.elevator_init_fn		= noop_init_queue,
		.elevator_exit_fn		= noop_exit_queue,
	},
	.elevator_name = "noop",
	.elevator_owner = THIS_MODULE,
};

static int __init noop_init(void)
{
	elv_register(&elevator_noop);

	return 0;
}

static void __exit noop_exit(void)
{
	elv_unregister(&elevator_noop);
}

module_init(noop_init);
module_exit(noop_exit);

Linux noop io 调度算法分析,码迷,mamicode.com

时间: 2024-10-09 19:01:07

Linux noop io 调度算法分析的相关文章

linux IO调度

I/O 调度算法再各个进程竞争磁盘I/O的时候担当了裁判的角色.他要求请求的次序和时机做最优化的处理,以求得尽可能最好的整体I/O性能.在linux下面列出4种调度算法CFQ (Completely Fair Queuing 完全公平的排队)(elevator=cfq): 这是默认算法,对于通用服务器来说通常是最好的选择.它试图均匀地分布对I/O带宽的访问.在多媒体应用, 总能保证audio.video及时从磁盘读取数据.但对于其他各类应用表现也很好.每个进程一个queue,每个queue按照上

Linux IO 调度器

Linux IO Scheduler(Linux IO 调度器) 每个块设备或者块设备的分区,都对应有自身的请求队列(request_queue),而每个请求队列都可以选择一个I/O调度器来协调所递交的request.I/O调度器的基本目的是将请求按照它们对应在块设备上的扇区号进行排列,以减少磁头的移动,提高效率.每个设备的请求队列里的请求将按顺序被响应.实际上,除了这个队列,每个调度器自身都维护有不同数量的队列,用来对递交上来的request进行处理,而排在队列最前面的request将适时被移

Linux IO Scheduler(Linux IO 调度器)

每个块设备或者块设备的分区,都对应有自身的请求队列(request_queue),而每个请求队列都可以选择一个I/O调度器来协调所递交的request.I/O调度器的基本目的是将请求按照它们对应在块设备上的扇区号进行排列,以减少磁头的移动,提高效率.每个设备的请求队列里的请求将按顺序被响应.实际上,除了这个队列,每个调度器自身都维护有不同数量的队列,用来对递交上来的request进行处理,而排在队列最前面的request将适时被移动到请求队列中等待响应. IO调度器在内核栈中所处位置如下: 内核

Linux操作系统结构、IO调度器在内核栈中的位置图

1.典型的Linux操作系统结构 2.IO调度器在内核栈中所处的位置 原文地址:https://blog.51cto.com/10627336/2356793

Linux deadline io 调度算法

deadline算法的核心就是在传统的电梯算法中加入了请求超时的机制,该机制主要体现在两点: 1.请求超时时,对超时请求的选择. 2.没有请求超时时,当扫描完电梯最后一个request后,准备返回时,对第一个request的选择.基于以上两点,平衡了系统i/o吞吐量和响应时间. 此外,该算法还考虑到了读操作对写操作造成的饥饿. 定义了elevator_deadline调度器类型: static struct elevator_type iosched_deadline = { .ops = {

修改numa和io调度优化mysql性能

一.NUMA设置单机单实例,建议关闭NUMA,关闭的方法有三种:1.硬件层,在BIOS中设置关闭:2.OS内核,启动时设置numa=off:3.可以用numactl命令将内存分配策略修改为interleave(交叉)方法3修改mySQL.server 330行加上numactlvi /opt/mysql/bin/mysql.server /usr/bin/numactl --interleave all $bindir/mysqld_safe --datadir=$datadir --pid-f

漫谈linux文件IO

原文转自:http://blog.chinaunix.net/uid-27105712-id-3270102.html 在Linux 开发中,有几个关系到性能的东西,技术人员非常关注:进程,CPU,MEM,网络IO,磁盘IO.本篇文件打算详细全面,深入浅出.剖析文件IO的细节.从多个角度探索如何提高IO性能.本文尽量用通俗易懂的视角去阐述.不copy内核代码. 阐述之前,要先有个大视角,让我们站在万米高空,鸟瞰我们的文件IO,它们设计是分层的,分层有2个好处,一是架构清晰,二是解耦.让我们看一下

ds6000com+Linux的CPU调度19908836661服务器的性能

我们可以在文章的开始就列出一个列表,列出可能影响Linux操作系统性能的一些调优参数,但这样做其实并没有什么价值.因为性能调优是一个非常困难的任务,它要求对硬件.操作系统.和应用都有着相当深入的了解.如果性能调优非常简单的话,那些我们要列出的调优参数早就写入硬件的微码或者操作系统中了,我们就没有必要再继续读这篇文章了.正如下图所示,服务器的性能受到很多因素的影响. 当面对一个使用单独IDE硬盘的,有20000用户的数据库服务器时,即使我们使用数周时间去调整I/O子系统也是徒劳无功的,通常一个新的

linux 同步IO: sync msync、fsync、fdatasync与 fflush

最近阅读leveldb源码,作为一个保证可靠性的kv数据库其数据与磁盘的交互可谓是极其关键,其中涉及到了不少内存和磁盘同步的操作和策略.为了加深理解,从网上整理了linux池畔同步IO相关的函数,这里做一个罗列和对比.大部分为copy,仅为记录,请各位看官勿喷. 传统的UNIX实现在内核中设有缓冲区高速缓存或页面高速缓存,大多数磁盘I/O都通过缓冲进行.当将数据写入文件时,内核通常先将该数据复制到其中一个缓冲区中,如果该缓冲区尚未写满,则并不将其排入输出队列,而是等待其写满或者当内核需要重用该缓