1 IO路径
从内核角度看，进程产生的IO路径主要有三条：
- 缓存IO：系统绝大部分IO走的这种形式，充分利用文件系统层的page cache所带来的优势。应用程序产生的IO经系统调用落入page cache之后便可以直接返回，page cache中的缓存数据由内核回写线程在适当时机同步到底层的存储介质上，当然应用程序也可以主动发起回写过程（如fsync系统调用）来确保数据尽快同步打扫存储介质上，从而避免系统崩溃或者掉电带来的数据不一致性；
- 非缓存IO（带蓄流）：这种IO绕过文件系统层的cache。用户在打开要读写的文件的时候需要加上
O_DIRECT标记，意为直接IO，不让文件系统的page cache介入。从用户角度而言，应用程序能直接控制的IO形式除了上面提到的缓存IO，剩下的IO都走这种形式，就算打开文件时加上了O_SYNC标记，最终产生的IO也会进入蓄流链表。如果应用程序在用户空间自己做了缓存，那么就可以使用这种IO方式，常见的如数据库应用； - 非缓存IO（不带蓄流）：内核通用快层的蓄流机制只给内核空间提供了接口来控制IO请求是否蓄流，用户空间进程无法控制提交的IO请求进入通用快层的时候是否蓄流。严格的说，用户空间直接产生的IO都会走蓄流路径，哪怕是提交IO的时候加上了
O_DIRECT和O_SYNC标记。用户空间间接产生的IO，如文件系统日志数据、元数据，有的不会走蓄流路径而是直接进入调度队列尽快得到调度。注意一点，通用块层的蓄流只是提供机制和接口而不是策略，也就是需不需要蓄流、何时蓄流完全由内核中的IO派发者决定；
2 合并方式
应用程序无论使用图中哪条IO路径，内核都会想方设法对IO进行合并。内核为促进这种合并，在IO栈上设置了三种合并方式以对应以上三种IO路径：
- Cache（页高速缓存）
- Plug list（蓄流链表）
- Elevator Queue（调度队列）
其中Cache属于文件系统层的内容，本文中不讨论，我们主要分析另外两种IO合并方式。
2.1 逻辑入口
blk_queue_io() 函数是通用块层进行IO合并的入口函数，该函数内先尝试Plug合并，合并成功返回，合并失败则继续尝试Elevator合并，合并成功返回，合并失败则为bio创建一个新的request插入到调度队列中，尝试IO合并部分的代码如下：
void blk_queue_io(struct request_queue *q, struct bio *bio)
{
const bool sync = !!(bio->bi_rw & REQ_SYNC);
struct blk_plug *plug;
int el_ret, rw_flags, where = ELEVATOR_INSERT_SORT;
struct request *req, *free;
unsigned int request_count = 0;
/*
* low level driver can indicate that it wants pages above a
* certain limit bounced to low memory (ie for highmem, or even
* ISA dma in theory)
*
* 做DMA时的相关地址限制，可能该bio只能访问低端内存，
* 因此需要将高端内存中的bio数据拷贝到低端内存中
*/
blk_queue_bounce(q, &bio);
/* 完整性校验 */
if (bio_integrity_enabled(bio) && bio_integrity_prep(bio)) {
bio_endio(bio, -EIO);
return;
}
/* FLUSH和FUA直接生成新的请求处理 */
if (bio->bi_rw & (REQ_FLUSH | REQ_FUA)) {
spin_lock_irq(q->queue_lock);
where = ELEVATOR_INSERT_FLUSH;
goto get_rq;
}
/*
* Check if we can merge with the plugged list before grabbing
* any locks.
*
* 先尝试plug合并，plug中为当前进程的req链表，合并成功直接返回
*/
if (!blk_queue_nomerges(q)) {
if (blk_attempt_plug_merge(q, bio, &request_count, NULL))
return;
} else
request_count = blk_plug_queued_count(q);
/* 不管是与队列中的请求合并还是插入新的请求都需要加锁 */
spin_lock_irq(q->queue_lock);
/* 这里记录下电梯哈希和调度算法调度队列
* bio生成新的请求后，会插入两个地方
* 1.电梯的通用哈希表，以请求的结束为止为哈希值进行哈希，
* 便于查找可以向后合并的请求
* q->elevator->hash
* 2.具体调度算法的调度队列，用于调度算法进行调度，以deadline为例
* q->elevator->elevator_data->sort_list/fifo_expire
*
* 调度算法派发请求后，请求会进入q的派发队列，
* 同时从哈希和调度队列中移除
*/
/* 在请求队列的哈希表中查找可以向后合并的请求，在调度算法
* 的调度队列中查找可以合并的请求（deadline算法中只有向前合并）
*/
el_ret = elv_merge(q, &req, bio);
if (el_ret == ELEVATOR_BACK_MERGE) {
/* 尝试进行bio与req的合并 */
if (bio_attempt_back_merge(q, req, bio)) {
/* 合并成功的话，调用具体调度算法的后续处理（deadline中并没有实现接口） */
elv_bio_merged(q, req, bio);
/* 这次合并的bio可能会弥补两个bio之间的空隙，所以这里查找根据
* 给定req后边的一个请求，判断能否进行合并
*/
free = attempt_back_merge(q, req);
if (!free)
/* 如果上边没有检测到可以合并的request，则调用接口处理
* bio合并到request之后的处理：
* 1.调用调度算法的回调函数处理调度算法需要执行的操作
* 2.如果是向后合并还需要更新电梯哈希
*/
elv_merged_request(q, req, el_ret);
else
__blk_put_request(q, free);
goto out_unlock;
}
} else if (el_ret == ELEVATOR_FRONT_MERGE) {
if (bio_attempt_front_merge(q, req, bio)) {
elv_bio_merged(q, req, bio);
free = attempt_front_merge(q, req);
if (!free)
elv_merged_request(q, req, el_ret);
else
__blk_put_request(q, free);
goto out_unlock;
}
}
get_rq:
/* bio无法合并，为其申请一个新的request */
/*
* This sync check and mask will be re-done in init_request_from_bio(),
* but we need to set it earlier to expose the sync flag to the
* rq allocator and io schedulers.
*/
rw_flags = bio_data_dir(bio);
if (sync)
rw_flags |= REQ_SYNC;
/*
* Grab a free request. This is might sleep but can not fail.
* Returns with the queue unlocked.
*/
blk_queue_enter_live(q);
/* 获取空闲的请求 */
req = get_request(q, rw_flags, bio, 0);
if (IS_ERR(req)) {
blk_queue_exit(q);
bio_endio(bio, PTR_ERR(req)); /* @q is dead */
goto out_unlock;
}
/*
* After dropping the lock and possibly sleeping here, our request
* may now be mergeable after it had proven unmergeable (above).
* We don't worry about that case for efficiency. It won't happen
* often, and the elevators are able to handle it.
*
* 根据bio初始化request
*/
init_request_from_bio(req, bio);
if (test_bit(QUEUE_FLAG_SAME_COMP, &q->queue_flags))
req->cpu = raw_smp_processor_id();
/* 如果当前进程有plug_list，首先插入到plug_list中 */
plug = current->plug;
if (plug) {
/*
* If this is the first request added after a plug, fire
* of a plug trace.
*
* @request_count may become stale because of schedule
* out, so check plug list again.
*/
if (!request_count || list_empty(&plug->list))
trace_block_plug(q);
else {
struct request *last = list_entry_rq(plug->list.prev);
if (request_count >= BLK_MAX_REQUEST_COUNT ||
blk_rq_bytes(last) >= BLK_PLUG_FLUSH_SIZE) {
blk_flush_plug_list(plug, false);
trace_block_plug(q);
}
}
/* 插入到plug链表 */
list_add_tail(&req->queuelist, &plug->list);
blk_account_io_start(req, true);
} else {
spin_lock_irq(q->queue_lock);
/* 插入到电梯及调度算法中 */
add_acct_request(q, req, where);
/* 执行q->request_fn(q)，调用底层驱动的策略例程处理请求。
* 以SCSI为例，request_fn初始化为scsi_request_fn
* scsi_request_fn->blk_peek_request->__elv_next_request
* __elv_next_request中会使用调度具体算法的
* dispatch回调函数取出请求进行处理
*/
__blk_run_queue(q);
out_unlock:
spin_unlock_irq(q->queue_lock);
}
}
2.2 Plug合并
Plug合并是内核通用块层提供的机制，如果需要开启则在提交IO前执行 blk_start_plug() 函数启动蓄流，IO全部提交完成后执行 blk_finish_plug() 函数进行泄流。启动蓄流主要是为当前进程（ current 宏）分配plug链表，提交IO时plug链表存在则IO先缓存到该链表中，执行泄流时将该链表中缓存的IO下发。执行plug合并的函数为 blk_attempt_plug_merge() ，该函数的主要逻辑为遍历 current->plug->list 中的所有请求，将属于同一个底层设备队列且位置相邻的请求合并在一起，代码逻辑如下：
bool blk_attempt_plug_merge(struct request_queue *q, struct bio *bio,
unsigned int *request_count,
struct request **same_queue_rq)
{
struct blk_plug *plug;
struct request *rq;
bool ret = false;
struct list_head *plug_list;
plug = current->plug;
if (!plug)
goto out;
*request_count = 0;
if (q->mq_ops)
plug_list = &plug->mq_list;
else
plug_list = &plug->list;
list_for_each_entry_reverse(rq, plug_list, queuelist) {
int el_ret;
/* 给plug_list中同一个设备的请求计数 */
if (rq->q == q) {
(*request_count)++;
/*
* Only blk-mq multiple hardware queues case checks the
* rq in the same queue, there should be only one such
* rq in a queue
**/
if (same_queue_rq)
*same_queue_rq = rq;
}
/* 同一队列，满足合并的才能合并 */
if (rq->q != q || !blk_rq_merge_ok(rq, bio))
continue;
/* 判断能进行合并的位置 */
el_ret = blk_try_merge(rq, bio);
if (el_ret == ELEVATOR_BACK_MERGE) {
ret = bio_attempt_back_merge(q, rq, bio);
if (ret)
break;
} else if (el_ret == ELEVATOR_FRONT_MERGE) {
ret = bio_attempt_front_merge(q, rq, bio);
if (ret)
break;
}
}
out:
return ret;
}
该逻辑中有两点需要注意。一是 request_count 计数，该变量统计plug链表中与当前IO属于同一队列的请求个数，当数量超过 BLK_MAX_REQUEST_COUNT （当前定义为16）时则主动下刷plug中的请求；二是函数 blk_rq_merge_ok() 与函数 blk_try_merge() ，其中 blk_rq_merge_ok() 检查req及bio属性是否支持合并， blk_try_merge() 则是根据req及bio的起始位置与长度来检查是否相邻，以判断能否合并以及合并的类型（前向/后向），代码如下：
bool blk_rq_merge_ok(struct request *rq, struct bio *bio)
{
/* rq_mergeable - 判断rq是否有不允许合并的标记
* bio_mergeable - 判断bio是否有不允许合并的标记
*/
if (!rq_mergeable(rq) || !bio_mergeable(bio))
return false;
/* 判断rq和bio是否是特殊的请求，
* 如果是特殊请求并且两者相同则不允许合并
*/
if (!blk_check_merge_flags(rq->cmd_flags, bio->bi_rw))
return false;
/* different data direction or already started, don't merge */
/* 请求方向不同，不能合并 */
if (bio_data_dir(bio) != rq_data_dir(rq))
return false;
/* must be same device and not a special request */
/* 指向的通用磁盘不同或者rq是特殊请求，不能合并 */
if (rq->rq_disk != bio->bi_bdev->bd_disk || req_no_special_merge(rq))
return false;
/* only merge integrity protected bio into ditto rq */
/* 完整性保护不同的请求和bio，不能合并 */
if (bio_integrity(bio) != blk_integrity_rq(rq))
return false;
/* must be using the same buffer */
/* REQ_WRITE_SAME请求，来自不同的page，不能合并 */
if (rq->cmd_flags & REQ_WRITE_SAME &&
!blk_write_same_mergeable(rq->bio, bio))
return false;
return true;
}
int blk_try_merge(struct request *rq, struct bio *bio)
{
/* rq结束位置等于bio起始位置返回后向合并 */
if (blk_rq_pos(rq) + blk_rq_sectors(rq) == bio->bi_sector)
return ELEVATOR_BACK_MERGE;
/* bio结束位置等于rq起始位置返回前向合并 */
else if (blk_rq_pos(rq) - bio_sectors(bio) == bio->bi_sector)
return ELEVATOR_FRONT_MERGE;
return ELEVATOR_NO_MERGE;
}
执行泄流操作的函数是 blk_flush_plug_list() ，代码逻辑如下：
void blk_flush_plug_list(struct blk_plug *plug, bool from_schedule)
{
struct request_queue *q;
unsigned long flags;
struct request *rq;
LIST_HEAD(list);
unsigned int depth;
BUG_ON(plug->magic != PLUG_MAGIC);
flush_plug_callbacks(plug, from_schedule);
if (!list_empty(&plug->mq_list))
blk_mq_flush_plug_list(plug, from_schedule);
if (list_empty(&plug->list))
return;
list_splice_init(&plug->list, &list);
/* 1.根据请求所在的q排序，这样可以优先处理同一设备的请求
* 2.同一设备的请求根据请求的起始位置排序，这样可以优化处理性能
*/
list_sort(NULL, &list, plug_rq_cmp);
q = NULL;
depth = 0;
/*
* Save and disable interrupts here, to avoid doing it for every
* queue lock we have to take.
*/
local_irq_save(flags);
while (!list_empty(&list)) {
rq = list_entry_rq(list.next);
list_del_init(&rq->queuelist);
BUG_ON(!rq->q);
/* 当 rq->q != q 时，说明一个队列的请求都已经取出，排查第一次，
* 当q为真时调用q->request_fn处理请求，q->request_fn会调用
* 具体的调度算法取出请求进行处理
*/
if (rq->q != q) {
/*
* This drops the queue lock
*/
if (q)
queue_unplugged(q, depth, from_schedule);
q = rq->q;
depth = 0;
spin_lock(q->queue_lock);
}
/*
* Short-circuit if @q is dead
*/
if (unlikely(blk_queue_dying(q))) {
__blk_end_request_all(rq, -ENODEV);
continue;
}
/*
* rq is already accounted, so use raw insert
*
* 在这里处理同一个队列的请求时，先将请求插入到调度队列和电梯
* 哈希中，同一队列全部插入完成后，在上边会一次性处理
*/
if (rq->cmd_flags & (REQ_FLUSH | REQ_FUA))
__elv_add_request(q, rq, ELEVATOR_INSERT_FLUSH);
else
__elv_add_request(q, rq, ELEVATOR_INSERT_SORT_MERGE);
depth++;
}
/*
* This drops the queue lock
* 处理最后一个设备的请求
*/
if (q)
queue_unplugged(q, depth, from_schedule);
local_irq_restore(flags);
}
2.3 Elevator合并
bio生成新的request后，会插入到两个位置。一是电梯调度算法的哈希表中，以request的结束位置为哈希值进行哈希，便于查找可以后向合并的请求，取值为 q->elevator->hash ；二是具体调度算法的调度队列，用于调度算法进行IO调度，以deadline调度算法为例，取值为 q->elevator->elevator_data->sort_list/fifo_expire 。调度算法派发请求后，请求会进入 q 的派发队列并同时从哈希和调度队列中移除。执行Elevator合并的函数为 elv_merge() ，主要包含电梯调度算法的后向合并以及具体IO调度算法的前向合并，并且为了提高合并效率，函数在最开始先检查最近一次合并成功的请求能否与bio进行合并。代码逻辑如下：
int elv_merge(struct request_queue *q, struct request **req, struct bio *bio)
{
struct elevator_queue *e = q->elevator;
struct request *__rq;
int ret;
/*
* Levels of merges:
* nomerges: No merges at all attempted
* noxmerges: Only simple one-hit cache try
* merges: All merge tries attempted
*
* 检查队列是否设置禁止合并的标记
*/
if (blk_queue_nomerges(q))
return ELEVATOR_NO_MERGE;
/*
* First try one-hit cache.
* 首先检测上次进行了合并的请求能否再次合并
*/
if (q->last_merge && elv_bio_merge_ok(q->last_merge, bio)) {
ret = blk_try_merge(q->last_merge, bio);
if (ret != ELEVATOR_NO_MERGE) {
*req = q->last_merge;
return ret;
}
}
if (blk_queue_noxmerges(q))
return ELEVATOR_NO_MERGE;
/*
* See if our hash lookup can find a potential backmerge.
* 在哈希中查找可能后向合并的请求
*/
__rq = elv_rqhash_find(q, bio->bi_sector);
if (__rq && elv_bio_merge_ok(__rq, bio)) {
*req = __rq;
return ELEVATOR_BACK_MERGE;
}
/* 调用具体调度算法的接口判断能否进行前向合并 */
if (e->uses_mq && e->aux->ops.mq.request_merge)
return e->aux->ops.mq.request_merge(q, req, bio);
else if (!e->uses_mq && e->aux->ops.sq.elevator_merge_fn)
return e->aux->ops.sq.elevator_merge_fn(q, req, bio);
return ELEVATOR_NO_MERGE;
}
2.4 前/后向合并
在结构体 struct request 中有两个成员分别是 struct bio *bio 和 struct bio *biotail ，成员 bio 表示还没有完成传输的第一个bio，成员 biotail 指向最后一个需要处理的bio。在结构体 struct bio 中有一个成员 struct bio *bi_next ，该成员指向下一个需要处理的bio，多个需要连续处理的bio通过该成员链接。
前向合并指的是将bio合并到req的前边，故基本逻辑为：
/* 将bio插入到req前边 */
bio->bi_next = req->bio;
req->bio = bio;
后向合并指的是将bio合并到req的后边，故基本逻辑为：
/* 将bio插入到req尾部 */
req->biotail->bi_next = bio;
req->biotail = bio;
标签：
留言评论