4.2 锁竞争量化

在 8 核 CPU 上运行 fio（4K 随机读，iodepth=64），单队列模式下的 queue_lock 争用会导致约 30-40% 的吞吐量损失。随着核数增加，损失趋近于 70% 以上。这正是 blk-mq 被提出的背景（2015 年 4.3 内核引入）。

五、blk-mq 多队列架构详解

5.1 架构设计：两层队列

blk-mq 引入了两层队列模型：

两层之间通过 blk_mq_hw_ctx->dispatch 链表连接：软件队列先将请求放入 dispatch 列表，再由驱动侧从 dispatch 列表中取出并写入硬件寄存器。

5.2 核心数据结构

struct blk_mq_tag_set {
    struct blk_mq_ops *ops;         // 驱动回调（queue_rq、commit_rqs）
    unsigned int       nr_hw_queues;     // 硬件队列数
    unsigned int       queue_depth;      // 每队列请求槽数
    unsigned int       cmd_size;         // 每命令私有数据大小
    int                numa_node;        // NUMA 节点
    struct blk_mq_tags **tags;           // hw_queue→blk_mq_tags 映射
    struct list_head   tag_list;         // 用户链表（共享 tag 的驱动间复用）
};

struct blk_mq_hw_ctx {
    struct blk_mq_queue_map map;         // sw→hw 映射
    struct list_head       dispatch;      // 待分发请求链表
    unsigned long          state;         // HCTX_INACTIVE/SCHED_BUSY 等
    struct sbitmap         ctx_bitmap;    // 软件 ctx 位图分配
    struct blk_mq_ctx    **ctxs;          // 拥有的软件上下文数组
    struct request_queue  *queue;         // 所属 request_queue
    atomic_t               nr_active;     // 活跃请求数
    // ...
};

struct blk_mq_ctx {
    struct blk_mq_hw_ctx *hctx;          // 归属的硬件队列
    spinlock_t            lock;          // 私有自旋锁（仅含 rq_queues 操作）
    struct list_head      rq_lists[HCTX_MAX_TYPES]; // 按优先级分类的请求列表
    unsigned int          cpu;           // 绑定的 CPU
    // ...
};

5.3 request 分配与 tag 机制

blk-mq 中每个 request 有一个全局唯一的 tag 编号，用于在命令完成时快速定位对应的 request。tag 分配通过 sbitmap（可扩展位图）高效实现：

// blk-mq-tag.c
unsigned int blk_mq_get_tag(struct blk_mq_alloc_data *data) {
    struct blk_mq_tags *tags = data->hctx->tags;
    struct sbitmap_queue = &tags->bitmap_tags;
    
    // sbitmap 原子分配一个 0-65535 的编号
    tag = sbitmap_queue_get(sbq, &data->ctx->index);
    if (tag != -1) {
        struct request *rq = tags->static_rqs[s_tag];
        rq->tag = tag;
        rq->internal_tag = -1;
        blk_mq_put_ctx(data->ctx);  // 释放 cpu 引用
    }
    return tag;
}

每个硬件队列拥有独立的 tag 空间（queue_depth 个槽位）。如果 tag 耗尽，blk_mq_get_tag() 返回 -1，软件队列进入 SCHED_BUSY 状态，停止接纳新请求直到有 tag 释放。

5.4 请求分发流程（blkmq_submit_bio）

void blk_mq_submit_bio(struct bio *bio) {
    struct request_queue *q = bio->bi_bdev->bd_disk->queue;
    struct blk_mq_hw_ctx *hctx;
    struct request *rq;
    blk_status_t ret;
    
    // 1. plug 检查：如果当前 plug 已满，先 flush
    if (blk_mq_sched_bio_merge(q, bio, &rq)) {
        // 合并进已有 request（返回 true）→ 直接返回
        return;
    }
    
    // 2. 根据映射关系选择 hw_ctx
    hctx = blk_mq_map_queue(q, cpu);
    
    // 3. 分配 request 和 tag
    rq = blk_mq_alloc_request(hctx, bio->bi_opf, 0);
    if (IS_ERR(rq)) {
        bio_io_error(bio);
        return;
    }
    
    // 4. bio → request 转换（初始化 request 各字段）
    blk_init_request_from_bio(rq, bio);
    
    // 5. Plugging 模式下：塞入 plug 列表，等待 flush
    if (plug) {
        blk_add_rq_to_plug(plug, rq);
    } else {
        // 直接下发
        blk_mq_try_issue_directly(hctx, rq);
    }
}

5.5 硬件队列映射策略

blk-mq 提供两种映射模式：

NVMe 驱动中可以通过 --nr_write_queues 和 --nr_poll_queues 参数调整写队列和轮询队列数量，实现更精细的 CPU 亲和控制。

六、I/O 调度器：从 elevator 到 blk-mq 调度器

6.1 传统 Elevator 调度器

在单队列时代，elevator 是一个可插拔的请求排序器，核心操作包括：

struct elevator_ops {
    .elevator_merge_fn      = * ElevatorMerge,    // 请求合并
    .elevator_merged_fn     = * ElevatorMerged,   // 合并后回调
    .elevator_merge_req_fn  = * ElevatorMergeReq, // request 间合并
    .elevator_dispatch_fn   = * ElevatorDispatch, // 从队列取出发给驱动
    .elevator_insert_fn     = * ElevatorInsert,   // 插入请求
    .elevator_remove_fn     = * ElevatorRemove,   // 移除请求
    .elevator_set_req_fn    = * ElevatorSetReq,   // 请求初始插入
    .elevator_init_fn       = * ElevatorInit,     // 初始化
    .elevator_exit_fn       = * ElevatorExit,     // 退出
};

常见调度算法：noop（无排序，仅合并）、deadline（按过期时间排序，写读分槽）、cfq（完全公平队列，每个进程独立队列）、bfq（预算公平，基于进程权重）。

6.2 blk-mq 调度器

blk-mq 时代引入了专门针对多队列架构的调度器（blk-mq-sched），通过额外的 调度队列 实现更细粒度的控制：

切换调度器很简单：

# 查看当前调度器
cat /sys/block/nvme0n1/queue/scheduler
[mq-deadline] kyber bfq none

# 临时切换
echo "bfq" > /sys/block/nvme0n1/queue/scheduler

# 永久生效（GRUB）
# GRUB_CMDLINE_LINUX="elevator=bfq"

6.3 bfq 深度解析

bfq（Budget Fair Queueing）是目前最复杂的 blk-mq 调度器，核心思想是每个进程有预算（budget），预算用完后切换到下一个进程：

• budget：每个进程在一次调度中可以发送的 I/O 字节数
• budget_timeout：在饥饿前的最小运行时间
• low_latency：低延迟模式（默认开启），自动调整权重
• bfq_weights：可手动设置进程的相对权重

bfq 在桌面 GUI 场景下能显著提升交互性，但在高并发服务器场景中表现不如 mq-deadline。

七、设备驱动层实战：NVMe 与 SCSI-MQ

7.1 NVMe 与 blk-mq 的深度契合

NVMe（Non-Volatile Memory Express）是专为 SSD 设计的协议，其硬件原生支持 64K 深度队列（每个队列 64K 个命令）。blk-mq 的架构与 NVMe 硬件完美匹配：

// drivers/nvme/host/pci.c
static const struct blk_mq_ops nvme_mq_ops = {
    .queue_rq       = nvme_queue_rq,      // 接收一个 request
    .commit_rqs     = nvme_commit_rqs,    // 批量提交到硬件（优化门铃写入）
    .get_budget     = nvme_get_budget,    // tag 预算（可选）
    .release_budget = nvme_release_budget, // 释放预算
    .complete       = nvme_pci_complete_rq, // I/O 完成回调
    .init_hctx      = nvme_init_hctx,     // 硬件队列初始化
    .init_request   = nvme_init_request,  // request 初始化
    .map_queues     = nvme_mq_map_queues,// SW→HW 映射
    .timeout        = nvme_timeout,        // 请求超时处理
    .poll           = nvme_poll,           // 轮询模式
};

// 核心路径：提交一个 request 到 NVMe
static blk_status_t nvme_queue_rq(struct blk_mq_hw_ctx *hctx,
                                   const struct blk_mq_queue_data *bd)
{
    struct request *req = bd->rq;
    struct nvme_dev *dev = hctx->driver_data;
    struct nvme_command *cmd = nvme_cmd(req);
    
    // 1. 分配 nvme_command（SQ slot）
    // 2. 将 request 翻译为 NVMe 命令（读/写/flush）
    memset(cmd, 0, sizeof(*cmd));
    if (req_op(req) == REQ_OP_FLUSH)
        nvme_setup_flush(ns, cmd);
    else if (req_op(req) == REQ_OP_WRITE)
        nvme_setup_write_cmd(ns, req);
    else
        nvme_setup_read_cmd(ns, req);
    
    // 3. 锁定队列并写入 SQ tail
    spin_lock_irq(>dev->q_lock[nvmeq->qid]);
    memcpy(nvmeq->sq_cmds + nvmeq->sq_tail, cmd, sizeof(*cmd));
    if (++nvmeq->sq_tail == nvmeq->q_depth)
        nvmeq->sq_tail = 0;
    writel(nvmeq->sq_tail, nvmeq->doorbell_addr);
    spin_unlock_irq(>dev->q_lock[nvmeq->qid]);
    
    return BLK_STS_OK;
}

关键点：commit_rqs 回调在 queue_rq 批量调用之后，只写一次门铃寄存器，避免了多次 MMIO 开销，这是 blk-mq 新增的批量提交优化。

7.2 SCSI-MQ（scsi-mq）适配

传统 SCSI 驱动基于单队列，Linux 4.17+ 引入了 scsi-mq 适配层，让 VirtIO-SCSI、SAS 等传统设备也能使用 blk-mq。scsi_mq_ops 提供了类似 NVMe 的抽象：

// drivers/scsi/scsi_lib.c
static const struct blk_mq_ops scsi_mq_ops = {
    .queue_rq   = scsi_queue_rq,
    .commit_rqs = scsi_commit_rqs,
    .complete   = scsi_softirq_done,
    .init_request = scsi_init_request,
    .exit_request = scsi_exit_request,
    .map_queues = scsi_map_queues,
    .show_rq    = scsi_show_rq,
};

// scsi_mq 使用 host-wide tag pool（共享所有硬件队列的 tag 空间）
static int scsi_alloc_request(struct blk_mq_hw_ctx *hctx, ...)
{
    struct Scsi_Host *shost = hctx->driver_data;
    int tag = scsi_get_tag(shost);
    // 分配 scsi_cmnd 并关联到 request
}

八、io_uring 与 blk-mq 联动

io_uring 是 Linux 5.1 引入的新一代异步 I/O 接口，在支持 IORING_SETUP_SQPOLL 的轮询模式下，可以直接将固定 buffer 提交到 NVMe 硬件队列（bypass VFS → 块设备层），但普通读写仍需经过块设备层的 blk-mq 调度。

io_uring 与 blk-mq 联动时的关键优化点：

• Fixed buffers：预注册 buffer，避免每次 get_user_pages() 开销
• Linked SQEs：链式提交，保证 I/O 顺序
• Polled I/O：IORING_SETUP_IOPOLL，直接轮询 NVMe CQ 硬件完成事件（bypass 中断 + softirq）
• SQPOLL 模式：内核线程轮询提交队列，减少用户态→内核态切换

性能对比（4K 随机读，单盘 NVMe SSD）：

九、全链路延迟剖析

一个 4K 随机读请求从发起到完成的完整延迟包含以下阶段：

使用 bpftrace 跟踪可以精确量化每一阶段：

# 跟踪 bio 提交到完成的全链路
bpftrace -e '
kprobe:submit_bio {
    @start[arg0] = nsecs;
}
kprobe:blk_mq_submit_bio {
    $bio = (struct bio *)arg0;
    $start = @start[$bio];
    if($start) {
        @submit_lat = hist(nsecs - $start);
        delete(@start[$bio]);
    }
}
kprobe:nvme_queue_rq {
    $start = @start[0];
    @hwqueue_lat = hist(nsecs - $start);
}

十、生产环境最佳实践

10.1 块设备层调优参数

# 1. 调度器选择
# NVMe SSD → mq-deadline 或 kyber
echo "mq-deadline" > /sys/block/nvme0n1/queue/scheduler
# 混合读写负载 → kyber
echo "kyber" > /sys/block/nvme2n1/queue/scheduler

# 2. nr_requests（队列最大未完成请求数）
# NVMe 可增加值以利用硬件并行性
echo 1024 > /sys/block/nvme0n1/queue/nr_requests

# 3. queue_depth（硬件驱动级深度）
# NVMe 中通常设置为 1024-4096
echo 4096 > /sys/block/nvme0n1/queue/nr_requests

# 4. read_ahead_kb（预读窗口）
# 顺序读场景增加预读（128-256KB）
echo 256 > /sys/block/nvme0n1/queue/read_ahead_kb

# 5. rq_affinity（CPU 亲和性）
# 2: 完成时回到提交它的 CPU（适合 Polling）
echo 2 > /sys/block/nvme0n1/queue/rq_affinity

# 6. io_poll_delay（轮询延迟（polling queue））
# 设为 -1 = 纯轮询，0 = 自适应，正数 = 中断超时后开始轮询
echo 0 > /sys/block/nvme0n1/queue/io_poll

10.2 blk-mq 的 NUMA 优化

在 NUMA 多 socket 服务器上，blk-mq 的 NUMA 亲和对性能影响显著：

# 查看当前 hw queue 到 NUMA 节点的映射
cat /sys/block/nvme0n1/mq/*/cpu_list
# 输出如：16,17,18,19,20,21,22,23（NUMA node 1 的 CPU）

# 设置硬件队列映射到特定 NUMA 节点
echo "none" > /sys/block/nvme0n1/queue/nomerges  # 关闭合并（SSD 场景）

# 多 socket 场景：为每个 socket 创建独立的 hw queue
# 启动参数：
# nvme.poll_queues=8 nvme.io_queues=16

10.3 使用 eBPF 观测块设备层

BCC/bpftrace 提供了多个块设备层的观测工具：

# biolatency：I/O 延迟分布直方图
biolatency -m -d nvme0n1

# biosnoop：打印每个 I/O 的详细信息
biosnoop -d nvme0n1

# blkqdsnoop：blk_mq request 分发延迟
blkqdsnoop -d nvme0n1

# custom bpftrace：追踪 plug → flush 周期
bpftrace -e '
kprobe:blk_mq_flush_plug_list {
    printf("flush plug: cpu=%d reqs=%d\n", 
           curtask->cpu, 
           ((struct blk_plug *)arg0)->rq_count);
}'

10.4 故障排查清单

Linux 块设备层 stat 文件解读

/sys/block/\<dev\>/stat 是块设备层的性能统计接口。它输出 17 个数字，含义如下：

通过对比字段（读 I/O 数 + 合并数）/ 读 I/O 完成数，可以计算合并率。NVMe 场景合并率通常很低（<5%），传统 HDD 可达 30-60%。

总结与展望

Linux 块设备层是整个存储栈的中枢神经。本文从 bio 结构体出发，覆盖了其完整生命周期、请求合并机制、plugging 优化，以及从单队列到 blk-mq 多队列的架构演进。blk-mq 通过两层队列模型、per-cpu 软件队列、tag 位图分配、批量 commit 等创新，彻底解决了单队列时代的锁竞争和 NUMA 不友好问题，与现代 NVMe 硬件完美契合。

下一篇文章我们将继续深入块设备层实战系列，覆盖 Writeback 与脏页回写机制、Multi-Queue Block IO Queuing Mechanism 与 io_uring 深度集成、以及 blk-cgroup 资源隔离等主题。