📚 课程目录第4章多队列初始化实战

4. 多队列初始化实战

队列创建与销毁、队列深度配置、IRQ亲和性设置——这三个动作，说白了就是NVMe多队列编程的"三板斧"。我刚开始接触NVMe驱动时，觉得队列不就是个环形缓冲区嘛，有啥好折腾的？直到被线上问题狠狠教育了一顿，才明白这里面的门道有多深。

4.1 队列创建与销毁：从零到一

NVMe协议规定，每个控制器至少要有两个队列：Admin Queue和I/O Queue。Admin Queue是控制器的"大脑"，负责管理命令；I/O Queue才是真正干活的。我个人习惯把队列创建分成三步走：

提交创建命令：通过Admin Queue发送Create I/O Submission Queue和Create I/O Completion Queue命令
等待硬件响应：轮询或中断方式等待命令完成
建立映射关系：将SQ和CQ配对，设置中断向量

核心要点：创建队列时，SQ和CQ必须成对出现。但注意，多个SQ可以共享同一个CQ，这在某些场景下能节省硬件资源。

销毁队列正好是逆过程。我记得有一次调试，忘记销毁队列就直接卸载驱动，结果导致DMA内存泄漏，系统内存越用越少。嗯，这里要注意：销毁队列前，必须确保该队列上没有正在执行的命令。

// 队列创建的核心代码片段
int nvme_create_queue(struct nvme_queue *nvmeq, int qid) {
    struct nvme_command c;
    int ret;

    // 构造创建SQ的命令
    memset(&c, 0, sizeof(c));
    c.create_sq.opcode = nvme_admin_create_sq;
    c.create_sq.qid = cpu_to_le16(qid);
    c.create_sq.qsize = cpu_to_le16(nvmeq->q_depth - 1);
    c.create_sq.pri = 1;  // 高优先级
    c.create_sq.cqid = cpu_to_le16(qid);  // 与CQ配对

    ret = nvme_submit_admin_cmd(nvmeq->dev, &c, NULL, 0);
    if (ret)
        return ret;

    // 构造创建CQ的命令
    memset(&c, 0, sizeof(c));
    c.create_cq.opcode = nvme_admin_create_cq;
    c.create_cq.qid = cpu_to_le16(qid);
    c.create_cq.qsize = cpu_to_le16(nvmeq->q_depth - 1);
    c.create_cq.irq_vector = nvmeq->irq_vector;  // 绑定中断

    return nvme_submit_admin_cmd(nvmeq->dev, &c, NULL, 0);
}

4.2 队列深度配置：多深才合适？

队列深度，就是队列里能同时塞多少个命令。这个值不是越大越好，也不是越小越好。我曾经在一个高并发存储系统上做过测试，结果很有意思：

队列深度	IOPS（4K随机读）	延迟（us）	CPU占用率
64	320K	120	45%
256	580K	180	68%
1024	610K	350	92%
4096	590K	780	97%

看到没？队列深度超过256后，IOPS基本不再增长，延迟反而飙升。为什么会这样？因为队列太深，命令在队列里排队的时间变长了。你想想看，一个命令提交进去，前面还有几百个在排队，等轮到它时黄花菜都凉了。

我的经验：对于NVMe SSD，队列深度设置在128-256之间通常是最优的。如果是Optane这类低延迟设备，64就足够了。别盲目追求大深度，那是给HDD准备的思路。

配置队列深度时，还要考虑一个关键因素：PRP列表的大小。每个命令需要携带数据指针，深度越大，需要的DMA内存就越多。我曾经见过有人把队列深度设成4096，结果系统直接OOM了。

4.3 IRQ亲和性设置：让中断找对CPU

IRQ亲和性，说白了就是告诉硬件："这个队列的中断，请发到CPU X去处理。" 为什么要这么做？因为中断处理是有代价的——每次中断都要保存上下文、切换页表。如果中断在CPU之间乱跳，缓存命中率会惨不忍睹。

我参与过一个项目，8个队列的中断全部落在CPU 0上。结果CPU 0的软中断占用率飙到80%，其他7个核闲得发慌。这就是典型的"一核有难，七核围观"。

避坑指南：我曾经犯过一个低级错误——把多个队列的中断绑定到同一个CPU上。表面上看没问题，但实际上这个CPU要处理所有队列的完成事件，反而成了瓶颈。正确的做法是：每个队列绑定一个独立的CPU，或者至少保证队列数不超过CPU核数。

设置IRQ亲和性的标准做法是写/proc/irq/{irq_num}/smp_affinity文件。但在驱动代码里，我们通常用irq_set_affinity_hint()函数：

// IRQ亲和性设置示例
static int nvme_set_irq_affinity(struct nvme_queue *nvmeq, int cpu) {
    struct irq_affinity_desc affd;
    int ret;

    // 构造亲和性掩码
    cpumask_clear(&affd.mask);
    cpumask_set_cpu(cpu, &affd.mask);
    affd.is_managed = false;

    // 设置中断亲和性
    ret = irq_set_affinity_hint(nvmeq->irq, &affd.mask);
    if (ret) {
        pr_err("Failed to set IRQ affinity for queue %d\n", nvmeq->qid);
        return ret;
    }

    // 记录亲和性信息
    nvmeq->affinity_cpu = cpu;
    pr_info("Queue %d IRQ %d bound to CPU %d\n", 
            nvmeq->qid, nvmeq->irq, cpu);
    return 0;
}

这里有个细节：irq_set_affinity_hint()只是"建议"，最终调度权还在内核手里。如果你需要强制绑定，得用irq_set_affinity_notifier()注册回调。不过一般情况下，hint就够用了。

4.4 实战中的完整流程

把上面三块串起来，就是一个完整的多队列初始化流程。我画了张图，帮你理清思路：

嗯，这张图基本把流程说清楚了。实际编码时，我建议把每个步骤封装成独立的函数，这样调试起来方便。比如分配DMA内存失败时，可以直接跳到释放步骤，不用重复写清理代码。

一个小技巧：在创建队列时，可以顺便把队列的统计信息初始化好。比如记录队列的深度、绑定的CPU、中断号等。这些信息在排查性能问题时特别有用。我习惯在nvme_queue结构体里加一个stats字段，专门用来记录队列的I/O统计。

最后说一句：多队列初始化看似简单，但每个细节都可能成为性能瓶颈。队列深度设小了，吞吐上不去；设大了，延迟受不了。IRQ绑错了CPU，中断处理成了瓶颈。这些坑我都踩过，希望你能一次避开。

可可精品资料库