Linux之块设备的多队列的实现机制

一、背景

在分析5.*版本的内核源码submit_bio() 函数，发现多队列机制是block layer的默认机制；之前老版本的 blk_queue_bio() 函数也被移除了； IO调度也被融合在多队列的制作需求的函数里（如果没有指定make_request 函数）。总之，内核block layer软件框架目前是走多队列的架构。

下面展示一下源码：

submit_bio（）：

复制代码

blk_qc_t submit_bio(struct bio *bio)
{
        bool workingset_read = false;
        unsigned long pflags;
        blk_qc_t ret;

        if (blkcg_punt_bio_submit(bio))
                return BLK_QC_T_NONE;

        /*
         * If it's a regular read/write or a barrier with data attached,
         * go through the normal accounting stuff before submission.
         */
        if (bio_has_data(bio)) {
                unsigned int count;

                if (unlikely(bio_op(bio) == REQ_OP_WRITE_SAME))
                        count = queue_logical_block_size(bio->bi_disk->queue) >> 9;
                else
                        count = bio_sectors(bio);

                if (op_is_write(bio_op(bio))) {
                        count_vm_events(PGPGOUT, count);
                } else {
                        if (bio_flagged(bio, BIO_WORKINGSET))
                                workingset_read = true;
                        task_io_account_read(bio->bi_iter.bi_size);
                        count_vm_events(PGPGIN, count);
                }

                if (unlikely(block_dump)) {
                        char b[BDEVNAME_SIZE];
                        printk(KERN_DEBUG "%s(%d): %s block %Lu on %s (%u sectors)\n",
                        current->comm, task_pid_nr(current),
                                op_is_write(bio_op(bio)) ? "WRITE" : "READ",
                                (unsigned long long)bio->bi_iter.bi_sector,
                                bio_devname(bio, b), count);
                }
        }

        /*
         * If we're reading data that is part of the userspace
         * workingset, count submission time as memory stall. When the
         * device is congested, or the submitting cgroup IO-throttled,
         * submission can be a significant part of overall IO time.
         */
        if (workingset_read)
                psi_memstall_enter(&pflags);

        ret = generic_make_request(bio);

        if (workingset_read)
                psi_memstall_leave(&pflags);

        return ret;
}
EXPORT_SYMBOL(submit_bio);

-》generic_make_request（）

复制代码

blk_qc_t generic_make_request(struct bio *bio)
{
        /*
         * bio_list_on_stack[0] contains bios submitted by the current
         * make_request_fn.
         * bio_list_on_stack[1] contains bios that were submitted before
         * the current make_request_fn, but that haven't been processed
         * yet.
         */
        struct bio_list bio_list_on_stack[2];
        blk_qc_t ret = BLK_QC_T_NONE;

        if (!generic_make_request_checks(bio))
                goto out;

        /*
         * We only want one ->make_request_fn to be active at a time, else
         * stack usage with stacked devices could be a problem.  So use
         * current->bio_list to keep a list of requests submited by a
         * make_request_fn function.  current->bio_list is also used as a
         * flag to say if generic_make_request is currently active in this
         * task or not.  If it is NULL, then no make_request is active.  If
         * it is non-NULL, then a make_request is active, and new requests
         * should be added at the tail
         */
        if (current->bio_list) {
                bio_list_add(&current->bio_list[0], bio);
                goto out;
        }

        /* following loop may be a bit non-obvious, and so deserves some
         * explanation.
         * Before entering the loop, bio->bi_next is NULL (as all callers
         * ensure that) so we have a list with a single bio.
         * We pretend that we have just taken it off a longer list, so
         * we assign bio_list to a pointer to the bio_list_on_stack,
         * thus initialising the bio_list of new bios to be
         * added.  ->make_request() may indeed add some more bios
         * through a recursive call to generic_make_request.  If it
         * did, we find a non-NULL value in bio_list and re-enter the loop
         * from the top.  In this case we really did just take the bio
         * of the top of the list (no pretending) and so remove it from
         * bio_list, and call into ->make_request() again.
         */
        BUG_ON(bio->bi_next);
        bio_list_init(&bio_list_on_stack[0]);
        current->bio_list = bio_list_on_stack;
        do {
                struct request_queue *q = bio->bi_disk->queue;
                blk_mq_req_flags_t flags = bio->bi_opf & REQ_NOWAIT ?
                        BLK_MQ_REQ_NOWAIT : 0;

                if (likely(blk_queue_enter(q, flags) == 0)) {
                        struct bio_list lower, same;

                        /* Create a fresh bio_list for all subordinate requests */
                        bio_list_on_stack[1] = bio_list_on_stack[0];
                        bio_list_init(&bio_list_on_stack[0]);
                        ret = q->make_request_fn(q, bio); // 重点是u这个函数

                        blk_queue_exit(q);

                        /* sort new bios into those for a lower level
                         * and those for the same level
                         */
                        bio_list_init(&lower);
                        bio_list_init(&same);
                        while ((bio = bio_list_pop(&bio_list_on_stack[0])) != NULL)
                                if (q == bio->bi_disk->queue)
                                        bio_list_add(&same, bio);
                                else
                                        bio_list_add(&lower, bio);
                        /* now assemble so we handle the lowest level first */
                        bio_list_merge(&bio_list_on_stack[0], &lower);
                        bio_list_merge(&bio_list_on_stack[0], &same);
                        bio_list_merge(&bio_list_on_stack[0], &bio_list_on_stack[1]);
                } else {
                        if (unlikely(!blk_queue_dying(q) &&
                                        (bio->bi_opf & REQ_NOWAIT)))
                                bio_wouldblock_error(bio);
                        else
                                bio_io_error(bio);
                }
                bio = bio_list_pop(&bio_list_on_stack[0]);
        } while (bio);
        current->bio_list = NULL; /* deactivate */

out:
        return ret;
}
EXPORT_SYMBOL(generic_make_request);

-》q->make_request_fn(q, bio)；

这个函数是在什么地方赋值的？是通过blk_queue_make_request（）函数声明；

内核源码搜出来有以上一些制造request 的函数。对于SSD硬盘驱动，走的就是blk_mq_make_request，当然对于一些其他ramdisk 或者 dm(RAID)/md (LVM2)虚拟化的设备，有特点的制造需求函数；目前先分析多队列函数的实现。

二、多队列框架前世今生

2.1 多队列出现的原因

Linux上传统的块设备层（Block Layer）和IO调度器（如cfq）主要是针对HDD（hard disk drivers）设计的。我们知道，HDD设备的随机IO性能很差，吞吐量大约是几百IOPS（IOs per second），延迟在毫秒级，所以当时IO性能的瓶颈在硬件，而不是内核。但是，随着高速SSD（Solid State Disk）的出现并展现出越来越高的性能，百万级甚至千万级IOPS的数据访问已成为一大趋势，传统的块设备层已无法满足这么高的IOPS需求，逐渐成为系统IO性能的瓶颈。

为了适配现代存设备（高速SSD等)高IOPS、低延迟的IO特征，新的块设备层框架Block multi-queue（blk-mq）应运而生。

历史上：

Linux上传统块设备层使用单队列（Single-queue/SQ）架构，具体实现如图：

因为什么原因被淘汰了？

主要来自三个方面：

请求队列锁竞争：blk-sq使用spinlock（q->queue_lock）来同步IO请求队列的访问，每次往请求队列中插入或删除IO请求，必须先获取此锁；IO提交时如果操作请求队列，必须先获取此锁；IO排序和调度操作时，也必须先获取此锁。这一系列操作继续之前，必须先获得请求队列锁，在高IOPS场景（多个线程同时提交IO请求）下，势必引起剧烈的锁竞争，带来不可忽视的软件开销。Linux- 2.6.32 中scsi+blk-sq，高IOPS场景下，约80%的cpu时间耗费在锁获取上。
硬件中断：高的IOPS意味着高的中断数量。在多数情况下，完成一次IO需要两次中断，一次是存储器件触发的硬件中断，另一次是IPI核间中断用于触发其他cpu上的软中断。
远端内存访问：如果提交IO请求的cpu不是接收硬件中断的cpu且这两个cpu没有共享缓存，那么获取请求队列锁的过程中还存在远端内存访问问题。

2.2 多队列框架的出现和解决的问题

针对blk-sq存在的问题，Jens Axboe （Linux内核Block Layer Maintainer）提出了多队列（multi-queue/MQ）的块设备层架构（blk-mq），如图4所示：

blk-mq中使用了两层队列，将单个请求队列锁的竞争分散多个队列中，极大的提高了Block Layer并发处理IO的能力。两层队列的设计分工明确:

软件暂存队列（Software Staging Queue）：blk-mq中为每个cpu分配一个软件队列，bio的提交/完成处理、IO请求暂存（合并、排序等）、IO请求标记、IO调度、IO记账都在这个队列上进行。由于每个cpu有单独的队列，所以每个cpu上的这些IO操作可以同时进行，而不存在锁竞争问题
硬件派发队列（Hardware Dispatch Queue）：blk-mq为存储器件的每个硬件队列（目前多数存储器件只有1个）分配一个硬件派发队列，负责存放软件队列往这个硬件队列派发的IO请求。在存储设备驱动初始化时，blk-mq会通过固定的映射关系将一个或多个软件队列映射（map）到一个硬件派发队列（同时保证映射到每个硬件队列的软件队列数量基本一致），之后这些软件队列上的IO请求会往对应的硬件队列上派发。

MQ架构解决了SQ架构中请求队列锁竞争和远端内存访问问题，极大的提高了Block Layer的IOPS吞吐量。从图5中，我们可以看到Linux 3.17-rc3 中scsi-mq+blk-mq，与图2相同的高IOPS场景下仅3%的cpu时间耗费在锁获取上。

scsi-mq_+blk-mq高IOPS场景下cpu热点数据：

图中：IOPS吞吐量随cpu数量的变化曲线，blk-mq更加接近raw设备的性能

三、多队列框架代码分析

blk-mq代码在Linux-3.13（2014）内核中合入主线，在Linux-3.16中成为内核的一个完整特性，在Linux-5.0内核中，blk-sq代码（包括基于blk-sq的IO调度器，如cfq、noop）已被完全移除，MQ成为Linux Block layer的默认选项。下面基于Linux-5.6.0内核介绍blk-mq代码和关键数据结构。

request 和bio 数据结构体就不介绍了，之前文章介绍的很详细了。

下面先介绍需要用到的数据结构体：blk_mq_tag_set和blk_mq_tags

硬件队列（blk_mq_hw_ctx）和软件队列（blk_mq_ctx）：

blk-mq中，request和tag是绑定的。

blk_mq_tags，用于描述tag和request的集合，它的主要成员如下：

blk_mq_tag_set，用于描述与存储器件相关的tag集合，抽象了存储器件的IO特征，它的主要成员如下：

与SQ框架一样，MQ框架中使用request结构体来描述IO请求；不同的是，SQ使用内存池来分配request结构体（参见__get_request），在request往驱动派发时分配tag（参见blk_queue_start_tag），MQ中request和tag分配是绑定在一起的（参见blk_mq_get_request）, 具体表现为:

request内存分配在块设备驱动初始化时完成（通过调用blk_mq_alloc_tag_set），避免IO发生时request内存分配带来的开销
tag 作为request（static_rqs/rqs数组）的索引

3.1 下面介绍一下调用流程图

总图：

细分：

3.2 初始化设备tagset 参数

blk_mq_alloc_tag_set: 为一个或者多个请求队列分配tag和request集合（tag set可以是多个request queue共享的，例如UFS设备，一个host controller只有一个tag set，但器件可能划分成多个LU--Logical Unit，每个LU有单独的request queue, 这些不同的request queue共享一个tag set），主要流程如下：

设置硬件队列数量(nr_hw_queues)和映射表数量(nr_maps)
调用blk_mq_realloc_tag_set_tag 根据硬件队列数量扩展tags数组
调用blk_mq_update_queue_map更新映射表（map: cpu id->hw queue id）
调用blk_mq_alloc_rq_maps分配request和tag（队列深度可能会根据内存状态下调）

流程图如下：

scsi_mq_setup_tags（）源码：

在标记2 框中，有 scsi_mq_ops 操作函数，将scsi层与block层交互的函数挂载到tag_set->ops上. 这些回调函数，是block 层下发request 到驱动的回调函数。

block 层和scsi 层的关系：

blk_mq_alloc_tag_set:

3.3 初始化设备 request_queue

scsi-mq驱动创建scsi device时初始化requst_queue流程:

scsi_add_device() ->scsi_probe_and_add_lun()

基于blk-mq的块设备驱动初始化时，通过调用blk_mq_init_queue初始化IO请求队列（request_queue)。例如，scsi-mq驱动中，每次添加scsi设备（scsi_device）时都会调用blk_mq_init_queue接口来初始化scsi设备的请求队列。 blk_mq_init_queue：初始化IO请求队列--request_queue。函数的主要流程如下：

调用blk_alloc_queue_node分配请求队列的内存，分配的内存节点与设备连接的NUMA节点一致，避免远端内存访问问题。
调用blk_mq_init_allocated_queue初始化分配的请求队列（request_queue），blk-mq的request_queue中包含两层队列，即percpu的软件队列（ctx）和与块设备硬件队列一一对应的硬件派发队列（hctx）。这个初始化过程主要包含下面几步：

1.设置队列的mq_ops（q->mq_ops)为set->ops (例如scsi对应的实现是scsi_mq_ops)

2.设置request超时时间，初始化timeout_work（处理函数是blk_mq_timeout_work）

3.设置队列的make_request回调为blk_mq_make_request （bio的提交时会用到）

4.分配和初始化percpu软件队列（ctx）

5.关联request_queue和块设备的tag set

6.更新软件队列（ctx）到硬件派发队列（hctx）的映射关系（map: ctx->hctx）

3.4 submit_bio

blk-mq中，通过调用blk_mq_make_request将上层提交的bio封装成request并提交到块设备层，它的主要流程如下:

尝试与当前线程plug list（如果当前线程正在做IO plug）中的IO request合并
尝试与当前cpu软件队列中的IO request合并（如果使能调度器，且调度器实现bio_merge接口，则调用这个接口尝试与调度器队列中的IO request合并）
尝试IO请求的QoS（Quality of Service）限流（目前实现的QoS策略有wbt, io-latency cgroup, io-cost cgroup三种）
获取request，并将bio添加到request
生成request后，将request插入请求队列中，分下面几种情况
1.如果是fua/flush请求，则将request插入到flush队列，并调用blk_mq_run_hw_queue 启动请求派发

2.如果当前线程正在做IO plug且块设备是硬件单队列的（nr_hw_queues=1），则将request插入到当前线程的plug list

3.如果配置了调度器，则调用blk_mq_sched_insert_request将请求插入调度器队列（如果没有实现insert_requests接口，则插入到当前cpu的软件队列中）

4.如果是硬件多队列块设备上的同步IO请求，则调用blk_mq_try_issue_directly尝试将request直接派发到块设备驱动

5.其他情况，则调用blk_mq_sched_insert_request插入request（同case 3）

上面的提交bio 的重点：如果bio 不能合并，就获取一个request , 把bio 放进此request, 然后把request 放进软件队列。

1、 blk_mq_make_request() 这个函数就是实现bio 是否可以合并，如果不行，就在获取request.

IO请求的入口为blk_mq_make_request()，其中首先判断IO是否可以跟其他request合并，若无法合并再将IO转换为request进一步处理。

2、blk_mq_get_request: 为bio分配request

MQ中request占用的内存在块设备驱动初始化时分配完成（tags->static_rqs), tag作为数组的索引获取对应的request，因此MQ中分配request即分配tag（使用sbitmap标记对应tag的是否已被使用）。该函数的主要流程如下：

调用blk_mq_get_ctx 获取当前cpu的软件队列（ctx）
调用blk_mq_map_queue 找到软件队列（ctx）对应的硬件派发队列（hctx）
对于配置了调度器的队列，调用limit_depth限制队列深度（影响tag获取)；对于无调度器的队列，更新tag set的当前活跃队列数量（用于均分tag到不同request_queue）
调用blk_mq_get_tag获取tag, 可能因当前无可用tag进入iowait状态
调用blk_mq_rq_ctx_init 初始化tag对应的request（tags->static_rqs[tag]）

有一个问题：通过blk_mq_get_request()获取，期间有可能会因获取不到request而被io_schedule，进入iowait状态，那么iowait 到底在wait 什么？？

下一篇文章写 iowait 在wait 什么。

3.5 IO的派发（dispatch）

blk-mq中通过调用blk_mq_run_hw_queue派发IO请求到块设备驱动，MQ框架中存在很多的点会触发IO请求往块设备驱动派发，主要如下：

blk_mq_run_hw_queue: 启动硬件队列派发IO请求，可以是同步/异步的执行的。如果队列不在静默状态(quiesced)且有IO请求pending，则启动派发：

如果是同步派发，且当前cpu的软件队列映射到此硬件队列，则调用__blk_mq_run_hw_queue在当前线程上下文中执行IO请求派发
如果是异步派发，则启动延迟任务（hctx->run_work）执行IO请求派发

无论是同步还是异步的派发模式，最终都会调用__blk_mq_run_hw_queue派发IO请求，这个函数先检查执行的上下文，然后调用blk_mq_sched_dispatch_requests派发IO请求到块设备驱动，这个函数的主要流程如下：

如果硬件派发队列（hctx->dispatch）非空, 则先调用blk_mq_dispatch_rq_list派发这个队列中的IO请求
如果配置了调度器，则调用blk_mq_do_dispatch_sched 从调度队列中派发IO请求
如果队列繁忙（dispatch_busy记录繁忙状态），则调用blk_mq_do_dispatch_ctx 从软件队列（软件队列选取采用Round-Robin策略）中取1个IO请求派发
否则，取映射到这个硬件队列的所有软件队列上的IO请求，调用blk_mq_dispatch_rq_list派发

上述4种情况都会调用blk_mq_dispatch_rq_list 将IO请求派发到块设备驱动，这个函数使用块设备驱动实现的几个接口完成派发逻辑：

3.6 IO的完成（complete）

下面以UFS+scsi-mq驱动为例，讲解IO完成处理的过程，主要流程如图13所示：

UFS设备完成一个IO请求之后，触发中断， ufshc(UFS host controller)驱动负责处理这个中断（服务例程是ufshc_intr），通过中断状态寄存器（REG_INTERRUPT_STATUS）判断是否有IO请求完成（UTP_TRANSFER_REQ_COMPL位），通过对比门铃寄存器（REG_UTP_TRANSFER_REQ_DOOR_BELL）和outstanding_reqs的值（异或操作）取得完成的IO请求。对于每个完成的IO请求，调用scsi_done进入scsi 命令的完成处理流程
scsi-mq驱动中scsi_done的实现是scsi_mq_done，这个函数会调用blk-mq中的接口blk_mq_complete_request 进入块设备层的request完成处理流程
Block Layer对于request完成处理有4种方式，具体如下： 1.对于硬件单队列的块设备，调用__blk_complete_request处理。如果发起IO请求的cpu就是当前cpu或者和当前cpu共享缓存，则发起当前cpu上的block软中断，在block软中断中继续request完成处理流程

2.对于硬件单队列的块设备，如果不满足case 1的条件，则通过IPI（inter-processor interrupt）发起其他cpu上的block软中断，在block软中断继续request完成处理流程

3.对于硬件多队列设备，如果当前cpu与发起IO请求的cpu不共享缓存（且不是高优先级的IO请求），则调用__blk_mq_complete_request_remote发起远端cpu上的request完成处理流程（IPI）

4.对于硬件多队列设备，非上述情况，直接在当前cpu上（硬件中断上下文）继续request完成处理流程
上述4种情况，最后都会调用mq_ops->complete 继续处理request的完成，对于scsi-mq驱动，这个接口的实现是scsi_softirq_done，经过一系列过程调用后（参见图13），由req_bio_endio 完成bio

四、多队列IO调度器

事实上，在blk-mq框架一开始是不支持IO调度器的（Linux-3.13）。由于高速存储器件IO特征是高IOPS，低延迟，我们希望IO的软件开销尽可能低，而IO调度会增加软件开销，所以专门针对这类器件设计的blk-mq在一开始并没有加入IO调度的能力。

当时的Linux块设备层是SQ和MQ两套框架共存的（SQ用于HDD这样的慢速块设备驱动，MQ用于nvme这样的高速块设备驱动）。Linux Block Layer的发展趋势是希望能够使用一套框架同时满足慢速器件和高速器件的需求，所以blk-mq引入后，Linux上的块设备驱动程序开始往MQ框架迁移，在Linux-5.0上，所有基于SQ的块设备驱动都完成了向MQ框架的转化，Block Layer的SQ框架和相关IO调度器被完全移除。

我们知道对于慢速器件（特别是旋转磁盘，随机IO性能很差）来讲，IO调度是十分重要的，同时一些高速器件（特别是硬件单队列的器件，如emmc，ufs）也有IO调度的需求。

因此在Linux-4.11上，Jens Axboe在MQ框架上增加了IO调度的能力，同SQ框架一样，MQ中的IO调度器也是插件化的，框架提供一系列的接口，由具体的IO调度算法（如mq-deadline）实现这些接口：

目前基于blk-mq实现的IO调度器主要有下面几个：

mq-deadline: 根据IO请求的类型（read/write）分配不同的到期时间（deadline)，并将IO请求按照deadline排序，同时支持IO合并，派发时优先选择deadline最小的IO请求，以此来控制IO的延迟。它在Linux-4.11上合入主线，是mq调度器的默认选项。对这个调度器感兴趣的同学可以阅读参考资料8和源码（mq-deadline.c）进一步了解相关细节
bfq: budget fair queuing, 它在Linux-4.12上合入主线，主要针对的是慢速器件，如机械硬盘。它提供了IO排序、IO优先级、按权重均匀分配IO带宽和组调度的能力，它保证每个IO的最大延迟可控的同时充分利用器件IO带宽。它的缺点是调度的软件开销比较高，例如Arm CortexTM-A53 8核系统中，最高只能支持80KIOPS，因此不适用于高速器件（如百万级IOPS的SSD）。对这个调度器感兴趣的同学可以阅读参考资料9和源码（bfq-iosched.c)进一步了解相关细节
kyber: 它在Linux-4.12上合入主线，是一个真正意义上的mq调度器，适用于高速器件。它对不同类型的IO（read/write/discard/others）设置不同的延迟要求，分开调度，同时监控每个IO调度域的延迟情况，如果某个IO调度域的延迟过高，则动态增加这个IO调度域的队列深度，并减小延迟OK的IO调度域的队列深度，以达到控制IO延迟的目的。本质上这种调度算法倾向于优先调度延迟要求高的IO（如read）。对这个调度器感兴趣的同学可以阅读参考资料10和源码（kyber-iosched.c)进一步了解相关细节