我是在排查一台多核服务器上NVMe SSD吞吐异常时第一次被迫把块层的blk-mqBlock Multi-Queue数据结构从头到尾读了一遍。当时现象很诡异队列深度调高之后IO延迟反而变大单队列模型下积累的那些调优经验几乎全部失效。后来把所有线索串起来才发现问题不在驱动也不在设备而是块层多队列架构里软件队列、硬件队列、标签分配这几个数据结构之间的协作关系没有吃透。从那时起我就有个体会想读懂IO路径或者排查存储性能问题第一步永远是先弄清数据结构长什么样、为什么这样设计。这篇是blk-mq架构解析系列的第一篇聚焦数据结构我会从设计动机讲起逐个拆解request_queue、blk_mq_tag_set、blk_mq_ctx、blk_mq_hw_ctx、request这些核心结构同时解释它们之间的关联和初始化装配过程。适合对块设备子系统有概念、但还没深入读过blk-mq源码的同学。1. 传统单队列模型的瓶颈与blk-mq的设计动机1.1 单队列模型为什么撑不住高并发在blk-mq出现之前块层长期是单队列模型整个块设备只有一个请求队列所有CPU的IO请求都要先经过一把全局大锁再排队进入这个队列。硬件时代早期这种做法没什么问题磁盘本身随机IO能力就几百IOPSCPU提交请求的速度远不是瓶颈锁竞争根本体现不出来。但NVMe SSD普及之后情况完全变了。一块普通NVMe盘的随机读就能跑到几十万IOPS延迟几十微秒一个CPU核哪怕只负责提交IO单位时间内生成的请求数量也远超传统磁盘场景。多个CPU同时往一个请求队列里塞请求全局锁的竞争立刻成为热点。更麻烦的是所有CPU都要操作同一批链表节点和计数器一个CPU修改了某个字段其他CPU的缓存行全部失效这就是典型的伪共享问题。随着核数增加性能反而可能下降扩展性完全锁死在单队列的粒度上。我印象很深的一次实测在96核的机器上压一块NVMe盘单队列模型下跑到大约40万IOPS就再也不涨CPU开销反而持续升高perftop里全是spinlock和原子操作。那时候就确定了块层必须换架构否则存储设备性能提升得再快软件层也接不住。1.2 多队列架构的核心思路分而治之blk-mq的思路可以概括成一句话把原来一个队列承担的并发压力拆分成多个互不干扰的入口。内核对每个CPU维护一个blk_mq_ctx软件队列上下文提交IO时只锁自己的CPU上下文不再和其他CPU抢同一把锁。同时根据底层设备的能力在软件和硬件之间建立多个blk_mq_hw_ctx硬件队列上下文请求经过软件队列后按策略分发到不同的硬件队列最终由设备端的多个命令队列并行处理。这个设计很像超市收银台的演变一个收银台时所有顾客排一条长队互相拥挤改成多个收银台后顾客各自选一个柜台排队冲突大大减少。blk-mq里的多个收银台就是多个硬件队列而每个CPU优先选择自己最近的柜台则依赖CPU到硬件队列的映射表。理解这个设计动机很重要。后续所有数据结构几乎都是为了支撑分而治之这四个字blk_mq_ctx保证提交阶段的CPU隔离blk_mq_hw_ctx抽象底层并行能力blk_mq_tag_set统一管理每个队列的标签资源request则是贯穿整个路径的载体。数据结构不是凭空设计的每一个成员都对应一个真实存在的并发问题。2. 核心数据结构逐个拆解2.1 request_queue为什么它不是一条队列新接触blk-mq的人容易把request_queue想象成队列其实它是一个块设备的顶层上下文或者说一个总容器。每个块设备对应一个request_queue它并不直接存放待处理的请求而是持有整个多队列体系的所有重要指针指向blk_mq_tag_set的tag_set指针、按CPU编号索引的软件队列数组queue_ctx、按硬件队列编号索引的硬件队列数组queue_hw_ctx以及blk_mq_ops操作集、make_request_fn入口函数等。可以把它理解成一家公司的总部本身不直接干活但它知道各个部门怎么找、流程怎么走、各岗位配了几个人。只要拿到request_queue就能找到当前设备关联的所有软件队列和硬件队列再顺着指针找到标签管理器进而找到任意一个request。从代码结构上看request_queue是qblk_mq_ctx是ctxblk_mq_hw_ctx是hctx很多函数的参数都是这三个变量的组合读源码时只要认准它们主线就不会乱。request_queue还承担了一些策略配置比如队列深度上限、扇区大小、I/O统计信息、sysfs入口等。每个块设备在sysfs下的/sys/block/sda/目录本质上就是挂在request_queue上的属性展示。2.2 blk_mq_tag_set队列资源的总台账blk_mq_tag_set是驱动向blk-mq注册资源的入口它描述我这个设备能提供多少个硬件队列、每个队列允许多少并发请求。核心字段包括opsblk_mq_ops操作集、nr_hw_queues硬件队列数量、queue_depth每个硬件队列的标签深度、reserved_tags保留标签数、cmd_size每个请求附加的驱动私有数据大小、driver_data驱动私有指针、tags指向每个硬件队列的blk_mq_tags管理结构。为什么需要统一管理tags因为一个设备的所有硬件队列共享同一种资源规格驱动初始化时一次性把标签管理器、请求数组都创建好后续request_queue直接引用这套资源避免临时分配的开销和碎片。cmd_size是一个容易被忽略但很关键的字段每个request对象后面紧跟着一段驱动私有数据区NVMe驱动用它存放命令描述符尺寸就由cmd_size决定。reserved_tags的作用也值得一提。它预留一小部分tag专门给内存紧张或紧急场景使用。比如设备内部需要发一条管理命令但所有tag都被IO占满此时可以从保留tag池取一个确保关键路径不会饿死。普通IO能用的tag总量是queue_depth - reserved_tags调参时要注意这个差值。2.3 blk_mq_ctxCPU视角的软件队列blk_mq_ctx是per-CPU分配的结构每个CPU一个代表从当前CPU视角看请求先落在哪里。它的核心是一个自旋锁和一组请求链表。提交IO时内核通过raw_smp_processor_id()拿到当前CPU编号直接定位到对应的blk_mq_ctx加锁后把请求挂到链表上整个过程不触碰其他CPU的上下文。这个per-CPU隔离是多队列架构高性能的基础也是传统单队列无法实现的。blk_mq_ctx内部还会记录自己绑定到哪个硬件队列。因为CPU和硬件队列不是一对一的关系可能多个CPU绑定到同一个硬件队列也可能一个CPU绑定多个类型的硬件队列。index_hw[]数组就是用来记录在当前类型下这个ctx对应第几个硬件队列提交时用来快速找到目标hw_ctx。不过要澄清一点很多人以为blk_mq_ctx就是软件队列其实它更像是一个提交暂存点。请求挂在ctx的链表上只是第一步真正排队调度发生在硬件队列的dispatch链路上或者调度器队列中。ctx存在的核心意义是让提交这个动作在CPU之间无锁化而不是承担完整的排队逻辑。想到这个区别读后续调度代码会轻松很多。2.4 blk_mq_hw_ctx硬件能力的软件化身blk_mq_hw_ctx对应底层设备的一个硬件队列或者说一组可并行处理的命令槽位。它对驱动屏蔽了具体硬件差异即使底层是中断驱动的、轮询驱动的或者同一个控制器下多个物理队列复用的在软件层面都抽象成一个hw_ctx。每个hw_ctx有独立的锁、调度链表dispatch_busy_list、状态标记state、标签管理器指针tags以及queue_num编号。state字段包括BLK_MQ_S_STOPPED、BLK_MQ_S_TAG_ACTIVE等状态位。停止状态会被动态设置比如底层设备发生错误或需要重置时内核先把hw_ctx停掉暂停向该队列下发新请求等恢复后再标记运行。这个状态管理在故障排查时很有用看sysfs里hw_ctx的状态能快速判断设备是否处于某类异常中。新内核里blk_mq_hw_ctx还引入了类型字段type区分默认队列、只读队列、轮询队列。比如NVMe的轮询队列就属于HCTX_TYPE_POLL这种队列不走中断而是由应用程序主动轮询完成获得更低延迟。同一设备可以同时存在多种类型的hw_ctx它们复用同一个tag_set但分布在不同类型下。不同存储设备的队列拓扑差异很大所以这个抽象是必须的。2.5 request与tags请求的身份证和房卡request是IO路径上真正干活的载体也是多队列数据结构链条里最接近硬件的那一层。它的核心字段包括指向所属request_queue的q、指向软件队列的mq_ctx、指向硬件队列的mq_hctx、关联的bio链表、携带的tag和internal_tag、以及命令类型标志cmd_flags等。tag字段可能是理解整个多队列机制最关键的一个概念。每个请求在从标签池成功申请到一个tag后这个数字就成为它在整个硬件队列中的临时编号。NVMe协议里命令描述符直接携带command_id硬件完成时通过这个ID找到对应的request不需要做复杂的地址换算或链表查找。你可以把tag想象成停车场的号牌进场拿号码出场凭号码取车号码就是车辆在这个停车场里的身份凭证。internal_tag则用于内核内部的调度场景与外部设备看到的tag解耦允许内核在软件层有更多腾挪空间。request的存储位置也有讲究。它不是在提交时临时malloc出来的而是在blk_mq_tag_set初始化阶段就已经按照nr_rqs批量分配好存放在blk_mq_tags的rqs[]数组里。申请tag时拿到的其实是一个数组下标request对象直接从这个下标位置取。这种预分配索引定位的设计极大减少了IO热路径上的动态内存分配。2.6 blk_mq_ops驱动与内核的接口协议blk_mq_ops定义了驱动必须实现的一组回调函数相当于是内核块层和驱动打交道时签的协议。核心回调有queue_rq把request真正提交给硬件、complete硬件完成后触发的完成回调、init_request/exit_request初始化/释放request、map_queues建立CPU到硬件队列的映射、timeout超时处理、poll轮询模式下的完成检查。开发过存储驱动的同学会发现blk_mq_ops把块层负责什么、驱动负责什么划分得十分清楚。块层负责请求的生成、排队、调度、超时框架驱动只负责两件事把命令填好发给硬件以及在硬件完成时通知回来。queue_rq是热路径上的高频回调它的实现质量直接影响性能很多驱动在queue_rq里做命令填充时连内存屏障都要仔细斟酌。map_queues这个回调在多队列架构里地位特殊。它决定每个CPU的请求最终路由到哪个硬件队列常见的策略有按NUMA节点就近映射、按CPU编号取模、或者是驱动根据MSI-X中断向量布局做自定义映射。映射不合理时可能出现多个CPU争抢同一个硬件队列而另外一些队列空闲导致队列深度分布不均IO延迟稳定性变差。3. 数据结构如何协作一条IO的完整旅程3.1 从bio提交到request诞生上层文件系统或直接IO生成的bio最终会进入blk_mq_submit_bio。函数首先尝试做请求合并在当前CPU对应的blk_mq_ctx链表里查找是否有可以合并的request如果找到直接把bio挂到现有request上连tag分配都省了。合并失败时才走完整的分配路径通过blk_mq_get_ctx获得当前CPU的ctx再根据ctx找到绑定的hw_ctx最后从hw_ctx关联的blk_mq_tags里申请一个空闲tag。申请tag的过程经过sbitmap位图分配器它把位图分成多个word分片每个CPU优先操作自己的word从位图层面进一步减少缓存行竞争。拿到tag后从rqs[tag]取出预分配的request对象填充q、mq_ctx、mq_hctx、cmd_flags、bio等字段。这一步结束后数据结构的第一个关键链路就建立了q - tag_set - tags - rqs[tag] - request。3.2 从软件队列到硬件队列的流转request初始化完成后会被插入ctx的请求链表。如果启用了内核调度器比如mq-deadline请求先进调度器的排序队列等待调度器按批次分发如果使用none调度器请求直接从ctx迁移到hw_ctx的dispatch链表。随后blk_mq_run_hw_queue被触发最终在__blk_mq_run_hw_queue里遍历dispatch链表逐个调用ops-queue_rq把请求下发给设备。这个流转过程非常值得细读。硬件队列dispatch_busy_list是真正排队的地方而queue_rq是一次性尽量多地提交如果设备返回忙比如命令队列满请求会被放回或其他机制延迟重试。blk_mq_ctx和blk_mq_hw_ctx在这里的分工就体现出来了ctx负责快速收拢请求hw_ctx负责按硬件能力沉稳下发。再强调一次如果只看名字很容易把ctx当完整队列实际它不是。3.3 完成路径与tag回收设备完成命令后通过中断或轮询进入完成回调内核通过command_id也就是tag在rqs[]数组里直接拿到对应的request调用blk_mq_complete_request。这里会根据request是否为最后一个bio来触发bio_endio唤醒等待IO的进程。完成之后tag被归还给sbitmaprequest对象则复位部分字段等待下一次复用。整个完成路径几乎没有遍历操作所有定位都靠tag索引完成时间复杂度O(1)。这和单队列时代遍历队列找完成请求的思路完全不同也是blk-mq能支撑高IOPS的关键之一。我每次看这段代码都感叹tag设计得有多巧妙它既解决了硬件命令标识问题又解决了软件层请求索引问题一个字段串起了整条IO链路。4. 数据结构装配初始化流程解析4.1 驱动侧的初始化顺序blk-mq数据结构不是自动生成的而是由驱动在探测设备时手工装配起来。典型流程如下// 1. 定义并填充tag_set static struct blk_mq_tag_set my_tag_set {0}; my_tag_set.ops my_mq_ops; my_tag_set.nr_hw_queues num_possible_cpus(); // 硬件队列数 my_tag_set.queue_depth 1024; // 每个队列的命令槽位数 my_tag_set.cmd_size sizeof(struct my_private_cmd); // 扩展的私有数据 my_tag_set.reserved_tags 2; // 保留tag数 my_tag_set.flags BLK_MQ_F_SHOULD_MERGE; // 允许合并 // 2. 分配标签资源 blk_mq_alloc_tag_set(my_tag_set); // 3. 创建request_queue struct request_queue *q blk_mq_init_queue(my_tag_set);这里有一个容易忽略的点blk_mq_alloc_tag_set会立即分配所有硬件队列对应的blk_mq_tags和request数组也就是说tag资源在request_queue创建之前就已经就位了。这样设计的原因很实际request_queue需要持有完整的资源所有权后续IO热路径上不需要再动态扩容所有内存一次性给定减少运行时开销。irq/affinity信息也在这个阶段参与映射。map_queues回调会根据设备的中断向量布局或NUMA拓扑在tag_set里建立map[]映射表后续每个ctx通过查表知道自己该绑定哪个hw_ctx。这部分逻辑在设备支持MSI-X多中断时尤其重要队列数、中断数、CPU核数三者的匹配关系直接影响最终性能。4.2 关键参数选择的经验nr_hw_queues和queue_depth的选择需要结合底层设备能力不是越大越好。如果只是机械地设为CPU核数但设备实际只支持少量命令队列内核就会做无效映射多个hw_ctx共享同一个底层队列标签资源被均分反而降低单队列深度增加延迟。我在实际项目中遇到过配置128个hw_ctx、每队列深度256但设备有效队列只有8个的场景结果并发深度被压缩吞吐不升反降。一个保守且有效的做法是优先参考设备规格书里的最大队列数和每队列最大命令数再结合线上负载的IO深度需求取一个中间值。对于典型NVMe SSDnr_hw_queues取物理CPU核数或NUMA节点数通常没问题queue_depth在256到1024之间是常见区间。如果负载以高并发小IO为主可以适当调大深度如果延迟敏感深度不宜过大否则设备内部的排队时间会拉长。cmd_size同样不可忽略。它决定了每个request后面预留多少私有空间驱动需要足够的空间存放命令描述符、散列表、临时状态。设小了驱动在queue_rq里写数据会越界设大了浪费内存。一般按驱动私有结构体的实际大小对齐到cacheline即可。4.3 数据结构的现场还原初始化完成后整个数据结构处于可运行状态可以用几个关键方式验证它的布局查看/sys/block/dev/mq/目录能看到每个硬件队列的编号、CPU映射、队列深度等参数。通过/sys/kernel/debug/block/dev/下的debugfs节点可以观察每个hw_ctx的tag使用率、活请求数、dispatch统计。用crash工具在内核转储中顺着request_queue - queue_hw_ctx - tags逐级打印能直观看到各队列的请求分布。我在一次线上问题排查中用debugfs发现某个hw_ctx的tag使用率长期保持在95%以上而其他hw_ctx只有40%立刻意识到是CPU映射不均衡。顺着map表查下去果然是因为该设备的MSI-X中断亲和性配置有问题多个CPU被挤到同一个中断向量上。修正映射后tag使用率立即均衡IO延迟的尾部波动也消失了。这类问题不看数据结构的实际分布根本无从下手。5. 阅读源码与调优中的常见误区和实操心得5.1 四个最容易踩的认知误区误区一把request_queue当作一条队列。它只是一个容器真正的排队发生在ctx链表、调度器队列和hw_ctx dispatch链表上。如果带着请求队列就是放请求的地方的预期去读代码会在blk_mq_submit_bio里绕很久。误区二认为每个blk_mq_hw_ctx都对应一个物理硬件队列。软件抽象和硬件实现之间有映射关系但绝不是一一对应。有些设备上报的队列数大于实际可用队列数多个hw_ctx会复用一个硬件命令队列反过来一个hw_ctx也可以通过多个中断向量提升吞吐。理解这个抽象层级才能正确解释为什么队列数增加但性能没变的现象。误区三忽视internal_tag和外部tag的区别。驱动看到的是rq-tag它在命令里会被当作硬件侧的命令ID。而internal_tag用于内核内部调度可以独立于外部tag存在。分不清这两者看调度器代码时会疑惑为什么同一个请求有两个tag编号。误区四把per-CPU的ctx当作无锁的万能药。ctx确实减少了锁竞争但请求从ctx迁移到hw_ctx时仍然需要加锁调度器也可能引入新的锁。blk-mq优化的是大部分情况下各干各的不是完全没有锁。做锁竞争分析时应该同时观察ctx锁和hw_ctx锁的争用情况。5.2 我实测过的几个调优细节我在NVMe设备上做过一次对照实验一组使用全部CPU核作为hw_ctx数量另一组按NUMA节点收敛到少量hw_ctx每组各跑混合读写。结果在高IO深度下两组吞吐接近但hw_ctx较少的那组CPU开销明显更低延迟分布也更集中。原因在于NUMA节点内CPU访问本地内存和控制结构开销更小减少了跨节点访问。这提醒我们nr_hw_queues不是越大越好要结合CPU拓扑和设备支持情况综合设置。另一个细节是轮询队列的配置。开启io_poll和io_timeout特性后NVMe驱动会创建HCTX_TYPE_POLL类型的hw_ctx走轮询完成路径不再依赖中断。轮询适合极低延迟的场景但会持续占用CPU吞吐型业务不建议全局开启。理解type字段后你会明白poll队列默认和普通队列分开有独立的tag池和CPU映射这也是blk_mq_hw_ctx中type存在的意义。最后是tag深度的观察方法。直接看/sys/block/dev/mq/n/tags或debugfs节点中的active_requests能快速判断当前队列的并发压力。如果某个hw_ctx的active_requests长期接近上限说明该队列过载需要检查CPU映射是否均衡或者适当调大整体队列深度。5.3 推荐的学习路径读blk-mq源码时我的建议是不要按文件从头到尾翻而是按调用链分段推进。第一段读blk_mq_submit_bio和__blk_mq_alloc_request搞清ctx和tag的来源第二段读blk_mq_run_hw_queue和__blk_mq_run_hw_queue搞清请求如何从ctx流转到hw_ctx第三段读blk_mq_complete_request搞清完成路径如何靠tag定位request。三段读完数据结构的全貌基本就清晰了。配合调试工具效果更好。可以用perf在queue_rq挂上探针统计每个hw_ctx的调用频率和耗时也可以在内核中开启/sys/kernel/debug/block/dev/下的trace事件直接看到request从提到完成的完整生命周期。纸上得来终觉浅跟着trace走一遍比看十遍源码截图都管用。我个人在实际操作中最深的体会是读多队列架构的代码千万不要在一开始就钻到字段细节里。先把设计动机和整体分工刻在脑子里再回头去看字段每个成员的意义就会自动浮现。blk_mq_ctx负责提交隔离blk_mq_hw_ctx负责排队下发tag_set负责资源总控tag负责全链路索引这四句话就是整篇数据结构的骨架。下一篇我会接着讲控制路径上的核心机制包括请求分发、调度器如何与多队列协作、tag的实时状态追踪、超时与恢复流程以及我在实际场景中对这些机制做出的调优取舍。数据结构是静态的地图控制路径是动态的车流两者结合才算真正把blk-mq读完。
我是在排查一台多核服务器上NVMe SSD吞吐异常时第一次被迫把块层的blk-mqBlock Multi-Queue数据结构从头到尾读了一遍。当时现象很诡异队列深度调高之后IO延迟反而变大单队列模型下积累的那些调优经验几乎全部失效。后来把所有线索串起来才发现问题不在驱动也不在设备而是块层多队列架构里软件队列、硬件队列、标签分配这几个数据结构之间的协作关系没有吃透。从那时起我就有个体会想读懂IO路径或者排查存储性能问题第一步永远是先弄清数据结构长什么样、为什么这样设计。这篇是blk-mq架构解析系列的第一篇聚焦数据结构我会从设计动机讲起逐个拆解request_queue、blk_mq_tag_set、blk_mq_ctx、blk_mq_hw_ctx、request这些核心结构同时解释它们之间的关联和初始化装配过程。适合对块设备子系统有概念、但还没深入读过blk-mq源码的同学。1. 传统单队列模型的瓶颈与blk-mq的设计动机1.1 单队列模型为什么撑不住高并发在blk-mq出现之前块层长期是单队列模型整个块设备只有一个请求队列所有CPU的IO请求都要先经过一把全局大锁再排队进入这个队列。硬件时代早期这种做法没什么问题磁盘本身随机IO能力就几百IOPSCPU提交请求的速度远不是瓶颈锁竞争根本体现不出来。但NVMe SSD普及之后情况完全变了。一块普通NVMe盘的随机读就能跑到几十万IOPS延迟几十微秒一个CPU核哪怕只负责提交IO单位时间内生成的请求数量也远超传统磁盘场景。多个CPU同时往一个请求队列里塞请求全局锁的竞争立刻成为热点。更麻烦的是所有CPU都要操作同一批链表节点和计数器一个CPU修改了某个字段其他CPU的缓存行全部失效这就是典型的伪共享问题。随着核数增加性能反而可能下降扩展性完全锁死在单队列的粒度上。我印象很深的一次实测在96核的机器上压一块NVMe盘单队列模型下跑到大约40万IOPS就再也不涨CPU开销反而持续升高perftop里全是spinlock和原子操作。那时候就确定了块层必须换架构否则存储设备性能提升得再快软件层也接不住。1.2 多队列架构的核心思路分而治之blk-mq的思路可以概括成一句话把原来一个队列承担的并发压力拆分成多个互不干扰的入口。内核对每个CPU维护一个blk_mq_ctx软件队列上下文提交IO时只锁自己的CPU上下文不再和其他CPU抢同一把锁。同时根据底层设备的能力在软件和硬件之间建立多个blk_mq_hw_ctx硬件队列上下文请求经过软件队列后按策略分发到不同的硬件队列最终由设备端的多个命令队列并行处理。这个设计很像超市收银台的演变一个收银台时所有顾客排一条长队互相拥挤改成多个收银台后顾客各自选一个柜台排队冲突大大减少。blk-mq里的多个收银台就是多个硬件队列而每个CPU优先选择自己最近的柜台则依赖CPU到硬件队列的映射表。理解这个设计动机很重要。后续所有数据结构几乎都是为了支撑分而治之这四个字blk_mq_ctx保证提交阶段的CPU隔离blk_mq_hw_ctx抽象底层并行能力blk_mq_tag_set统一管理每个队列的标签资源request则是贯穿整个路径的载体。数据结构不是凭空设计的每一个成员都对应一个真实存在的并发问题。2. 核心数据结构逐个拆解2.1 request_queue为什么它不是一条队列新接触blk-mq的人容易把request_queue想象成队列其实它是一个块设备的顶层上下文或者说一个总容器。每个块设备对应一个request_queue它并不直接存放待处理的请求而是持有整个多队列体系的所有重要指针指向blk_mq_tag_set的tag_set指针、按CPU编号索引的软件队列数组queue_ctx、按硬件队列编号索引的硬件队列数组queue_hw_ctx以及blk_mq_ops操作集、make_request_fn入口函数等。可以把它理解成一家公司的总部本身不直接干活但它知道各个部门怎么找、流程怎么走、各岗位配了几个人。只要拿到request_queue就能找到当前设备关联的所有软件队列和硬件队列再顺着指针找到标签管理器进而找到任意一个request。从代码结构上看request_queue是qblk_mq_ctx是ctxblk_mq_hw_ctx是hctx很多函数的参数都是这三个变量的组合读源码时只要认准它们主线就不会乱。request_queue还承担了一些策略配置比如队列深度上限、扇区大小、I/O统计信息、sysfs入口等。每个块设备在sysfs下的/sys/block/sda/目录本质上就是挂在request_queue上的属性展示。2.2 blk_mq_tag_set队列资源的总台账blk_mq_tag_set是驱动向blk-mq注册资源的入口它描述我这个设备能提供多少个硬件队列、每个队列允许多少并发请求。核心字段包括opsblk_mq_ops操作集、nr_hw_queues硬件队列数量、queue_depth每个硬件队列的标签深度、reserved_tags保留标签数、cmd_size每个请求附加的驱动私有数据大小、driver_data驱动私有指针、tags指向每个硬件队列的blk_mq_tags管理结构。为什么需要统一管理tags因为一个设备的所有硬件队列共享同一种资源规格驱动初始化时一次性把标签管理器、请求数组都创建好后续request_queue直接引用这套资源避免临时分配的开销和碎片。cmd_size是一个容易被忽略但很关键的字段每个request对象后面紧跟着一段驱动私有数据区NVMe驱动用它存放命令描述符尺寸就由cmd_size决定。reserved_tags的作用也值得一提。它预留一小部分tag专门给内存紧张或紧急场景使用。比如设备内部需要发一条管理命令但所有tag都被IO占满此时可以从保留tag池取一个确保关键路径不会饿死。普通IO能用的tag总量是queue_depth - reserved_tags调参时要注意这个差值。2.3 blk_mq_ctxCPU视角的软件队列blk_mq_ctx是per-CPU分配的结构每个CPU一个代表从当前CPU视角看请求先落在哪里。它的核心是一个自旋锁和一组请求链表。提交IO时内核通过raw_smp_processor_id()拿到当前CPU编号直接定位到对应的blk_mq_ctx加锁后把请求挂到链表上整个过程不触碰其他CPU的上下文。这个per-CPU隔离是多队列架构高性能的基础也是传统单队列无法实现的。blk_mq_ctx内部还会记录自己绑定到哪个硬件队列。因为CPU和硬件队列不是一对一的关系可能多个CPU绑定到同一个硬件队列也可能一个CPU绑定多个类型的硬件队列。index_hw[]数组就是用来记录在当前类型下这个ctx对应第几个硬件队列提交时用来快速找到目标hw_ctx。不过要澄清一点很多人以为blk_mq_ctx就是软件队列其实它更像是一个提交暂存点。请求挂在ctx的链表上只是第一步真正排队调度发生在硬件队列的dispatch链路上或者调度器队列中。ctx存在的核心意义是让提交这个动作在CPU之间无锁化而不是承担完整的排队逻辑。想到这个区别读后续调度代码会轻松很多。2.4 blk_mq_hw_ctx硬件能力的软件化身blk_mq_hw_ctx对应底层设备的一个硬件队列或者说一组可并行处理的命令槽位。它对驱动屏蔽了具体硬件差异即使底层是中断驱动的、轮询驱动的或者同一个控制器下多个物理队列复用的在软件层面都抽象成一个hw_ctx。每个hw_ctx有独立的锁、调度链表dispatch_busy_list、状态标记state、标签管理器指针tags以及queue_num编号。state字段包括BLK_MQ_S_STOPPED、BLK_MQ_S_TAG_ACTIVE等状态位。停止状态会被动态设置比如底层设备发生错误或需要重置时内核先把hw_ctx停掉暂停向该队列下发新请求等恢复后再标记运行。这个状态管理在故障排查时很有用看sysfs里hw_ctx的状态能快速判断设备是否处于某类异常中。新内核里blk_mq_hw_ctx还引入了类型字段type区分默认队列、只读队列、轮询队列。比如NVMe的轮询队列就属于HCTX_TYPE_POLL这种队列不走中断而是由应用程序主动轮询完成获得更低延迟。同一设备可以同时存在多种类型的hw_ctx它们复用同一个tag_set但分布在不同类型下。不同存储设备的队列拓扑差异很大所以这个抽象是必须的。2.5 request与tags请求的身份证和房卡request是IO路径上真正干活的载体也是多队列数据结构链条里最接近硬件的那一层。它的核心字段包括指向所属request_queue的q、指向软件队列的mq_ctx、指向硬件队列的mq_hctx、关联的bio链表、携带的tag和internal_tag、以及命令类型标志cmd_flags等。tag字段可能是理解整个多队列机制最关键的一个概念。每个请求在从标签池成功申请到一个tag后这个数字就成为它在整个硬件队列中的临时编号。NVMe协议里命令描述符直接携带command_id硬件完成时通过这个ID找到对应的request不需要做复杂的地址换算或链表查找。你可以把tag想象成停车场的号牌进场拿号码出场凭号码取车号码就是车辆在这个停车场里的身份凭证。internal_tag则用于内核内部的调度场景与外部设备看到的tag解耦允许内核在软件层有更多腾挪空间。request的存储位置也有讲究。它不是在提交时临时malloc出来的而是在blk_mq_tag_set初始化阶段就已经按照nr_rqs批量分配好存放在blk_mq_tags的rqs[]数组里。申请tag时拿到的其实是一个数组下标request对象直接从这个下标位置取。这种预分配索引定位的设计极大减少了IO热路径上的动态内存分配。2.6 blk_mq_ops驱动与内核的接口协议blk_mq_ops定义了驱动必须实现的一组回调函数相当于是内核块层和驱动打交道时签的协议。核心回调有queue_rq把request真正提交给硬件、complete硬件完成后触发的完成回调、init_request/exit_request初始化/释放request、map_queues建立CPU到硬件队列的映射、timeout超时处理、poll轮询模式下的完成检查。开发过存储驱动的同学会发现blk_mq_ops把块层负责什么、驱动负责什么划分得十分清楚。块层负责请求的生成、排队、调度、超时框架驱动只负责两件事把命令填好发给硬件以及在硬件完成时通知回来。queue_rq是热路径上的高频回调它的实现质量直接影响性能很多驱动在queue_rq里做命令填充时连内存屏障都要仔细斟酌。map_queues这个回调在多队列架构里地位特殊。它决定每个CPU的请求最终路由到哪个硬件队列常见的策略有按NUMA节点就近映射、按CPU编号取模、或者是驱动根据MSI-X中断向量布局做自定义映射。映射不合理时可能出现多个CPU争抢同一个硬件队列而另外一些队列空闲导致队列深度分布不均IO延迟稳定性变差。3. 数据结构如何协作一条IO的完整旅程3.1 从bio提交到request诞生上层文件系统或直接IO生成的bio最终会进入blk_mq_submit_bio。函数首先尝试做请求合并在当前CPU对应的blk_mq_ctx链表里查找是否有可以合并的request如果找到直接把bio挂到现有request上连tag分配都省了。合并失败时才走完整的分配路径通过blk_mq_get_ctx获得当前CPU的ctx再根据ctx找到绑定的hw_ctx最后从hw_ctx关联的blk_mq_tags里申请一个空闲tag。申请tag的过程经过sbitmap位图分配器它把位图分成多个word分片每个CPU优先操作自己的word从位图层面进一步减少缓存行竞争。拿到tag后从rqs[tag]取出预分配的request对象填充q、mq_ctx、mq_hctx、cmd_flags、bio等字段。这一步结束后数据结构的第一个关键链路就建立了q - tag_set - tags - rqs[tag] - request。3.2 从软件队列到硬件队列的流转request初始化完成后会被插入ctx的请求链表。如果启用了内核调度器比如mq-deadline请求先进调度器的排序队列等待调度器按批次分发如果使用none调度器请求直接从ctx迁移到hw_ctx的dispatch链表。随后blk_mq_run_hw_queue被触发最终在__blk_mq_run_hw_queue里遍历dispatch链表逐个调用ops-queue_rq把请求下发给设备。这个流转过程非常值得细读。硬件队列dispatch_busy_list是真正排队的地方而queue_rq是一次性尽量多地提交如果设备返回忙比如命令队列满请求会被放回或其他机制延迟重试。blk_mq_ctx和blk_mq_hw_ctx在这里的分工就体现出来了ctx负责快速收拢请求hw_ctx负责按硬件能力沉稳下发。再强调一次如果只看名字很容易把ctx当完整队列实际它不是。3.3 完成路径与tag回收设备完成命令后通过中断或轮询进入完成回调内核通过command_id也就是tag在rqs[]数组里直接拿到对应的request调用blk_mq_complete_request。这里会根据request是否为最后一个bio来触发bio_endio唤醒等待IO的进程。完成之后tag被归还给sbitmaprequest对象则复位部分字段等待下一次复用。整个完成路径几乎没有遍历操作所有定位都靠tag索引完成时间复杂度O(1)。这和单队列时代遍历队列找完成请求的思路完全不同也是blk-mq能支撑高IOPS的关键之一。我每次看这段代码都感叹tag设计得有多巧妙它既解决了硬件命令标识问题又解决了软件层请求索引问题一个字段串起了整条IO链路。4. 数据结构装配初始化流程解析4.1 驱动侧的初始化顺序blk-mq数据结构不是自动生成的而是由驱动在探测设备时手工装配起来。典型流程如下// 1. 定义并填充tag_set static struct blk_mq_tag_set my_tag_set {0}; my_tag_set.ops my_mq_ops; my_tag_set.nr_hw_queues num_possible_cpus(); // 硬件队列数 my_tag_set.queue_depth 1024; // 每个队列的命令槽位数 my_tag_set.cmd_size sizeof(struct my_private_cmd); // 扩展的私有数据 my_tag_set.reserved_tags 2; // 保留tag数 my_tag_set.flags BLK_MQ_F_SHOULD_MERGE; // 允许合并 // 2. 分配标签资源 blk_mq_alloc_tag_set(my_tag_set); // 3. 创建request_queue struct request_queue *q blk_mq_init_queue(my_tag_set);这里有一个容易忽略的点blk_mq_alloc_tag_set会立即分配所有硬件队列对应的blk_mq_tags和request数组也就是说tag资源在request_queue创建之前就已经就位了。这样设计的原因很实际request_queue需要持有完整的资源所有权后续IO热路径上不需要再动态扩容所有内存一次性给定减少运行时开销。irq/affinity信息也在这个阶段参与映射。map_queues回调会根据设备的中断向量布局或NUMA拓扑在tag_set里建立map[]映射表后续每个ctx通过查表知道自己该绑定哪个hw_ctx。这部分逻辑在设备支持MSI-X多中断时尤其重要队列数、中断数、CPU核数三者的匹配关系直接影响最终性能。4.2 关键参数选择的经验nr_hw_queues和queue_depth的选择需要结合底层设备能力不是越大越好。如果只是机械地设为CPU核数但设备实际只支持少量命令队列内核就会做无效映射多个hw_ctx共享同一个底层队列标签资源被均分反而降低单队列深度增加延迟。我在实际项目中遇到过配置128个hw_ctx、每队列深度256但设备有效队列只有8个的场景结果并发深度被压缩吞吐不升反降。一个保守且有效的做法是优先参考设备规格书里的最大队列数和每队列最大命令数再结合线上负载的IO深度需求取一个中间值。对于典型NVMe SSDnr_hw_queues取物理CPU核数或NUMA节点数通常没问题queue_depth在256到1024之间是常见区间。如果负载以高并发小IO为主可以适当调大深度如果延迟敏感深度不宜过大否则设备内部的排队时间会拉长。cmd_size同样不可忽略。它决定了每个request后面预留多少私有空间驱动需要足够的空间存放命令描述符、散列表、临时状态。设小了驱动在queue_rq里写数据会越界设大了浪费内存。一般按驱动私有结构体的实际大小对齐到cacheline即可。4.3 数据结构的现场还原初始化完成后整个数据结构处于可运行状态可以用几个关键方式验证它的布局查看/sys/block/dev/mq/目录能看到每个硬件队列的编号、CPU映射、队列深度等参数。通过/sys/kernel/debug/block/dev/下的debugfs节点可以观察每个hw_ctx的tag使用率、活请求数、dispatch统计。用crash工具在内核转储中顺着request_queue - queue_hw_ctx - tags逐级打印能直观看到各队列的请求分布。我在一次线上问题排查中用debugfs发现某个hw_ctx的tag使用率长期保持在95%以上而其他hw_ctx只有40%立刻意识到是CPU映射不均衡。顺着map表查下去果然是因为该设备的MSI-X中断亲和性配置有问题多个CPU被挤到同一个中断向量上。修正映射后tag使用率立即均衡IO延迟的尾部波动也消失了。这类问题不看数据结构的实际分布根本无从下手。5. 阅读源码与调优中的常见误区和实操心得5.1 四个最容易踩的认知误区误区一把request_queue当作一条队列。它只是一个容器真正的排队发生在ctx链表、调度器队列和hw_ctx dispatch链表上。如果带着请求队列就是放请求的地方的预期去读代码会在blk_mq_submit_bio里绕很久。误区二认为每个blk_mq_hw_ctx都对应一个物理硬件队列。软件抽象和硬件实现之间有映射关系但绝不是一一对应。有些设备上报的队列数大于实际可用队列数多个hw_ctx会复用一个硬件命令队列反过来一个hw_ctx也可以通过多个中断向量提升吞吐。理解这个抽象层级才能正确解释为什么队列数增加但性能没变的现象。误区三忽视internal_tag和外部tag的区别。驱动看到的是rq-tag它在命令里会被当作硬件侧的命令ID。而internal_tag用于内核内部调度可以独立于外部tag存在。分不清这两者看调度器代码时会疑惑为什么同一个请求有两个tag编号。误区四把per-CPU的ctx当作无锁的万能药。ctx确实减少了锁竞争但请求从ctx迁移到hw_ctx时仍然需要加锁调度器也可能引入新的锁。blk-mq优化的是大部分情况下各干各的不是完全没有锁。做锁竞争分析时应该同时观察ctx锁和hw_ctx锁的争用情况。5.2 我实测过的几个调优细节我在NVMe设备上做过一次对照实验一组使用全部CPU核作为hw_ctx数量另一组按NUMA节点收敛到少量hw_ctx每组各跑混合读写。结果在高IO深度下两组吞吐接近但hw_ctx较少的那组CPU开销明显更低延迟分布也更集中。原因在于NUMA节点内CPU访问本地内存和控制结构开销更小减少了跨节点访问。这提醒我们nr_hw_queues不是越大越好要结合CPU拓扑和设备支持情况综合设置。另一个细节是轮询队列的配置。开启io_poll和io_timeout特性后NVMe驱动会创建HCTX_TYPE_POLL类型的hw_ctx走轮询完成路径不再依赖中断。轮询适合极低延迟的场景但会持续占用CPU吞吐型业务不建议全局开启。理解type字段后你会明白poll队列默认和普通队列分开有独立的tag池和CPU映射这也是blk_mq_hw_ctx中type存在的意义。最后是tag深度的观察方法。直接看/sys/block/dev/mq/n/tags或debugfs节点中的active_requests能快速判断当前队列的并发压力。如果某个hw_ctx的active_requests长期接近上限说明该队列过载需要检查CPU映射是否均衡或者适当调大整体队列深度。5.3 推荐的学习路径读blk-mq源码时我的建议是不要按文件从头到尾翻而是按调用链分段推进。第一段读blk_mq_submit_bio和__blk_mq_alloc_request搞清ctx和tag的来源第二段读blk_mq_run_hw_queue和__blk_mq_run_hw_queue搞清请求如何从ctx流转到hw_ctx第三段读blk_mq_complete_request搞清完成路径如何靠tag定位request。三段读完数据结构的全貌基本就清晰了。配合调试工具效果更好。可以用perf在queue_rq挂上探针统计每个hw_ctx的调用频率和耗时也可以在内核中开启/sys/kernel/debug/block/dev/下的trace事件直接看到request从提到完成的完整生命周期。纸上得来终觉浅跟着trace走一遍比看十遍源码截图都管用。我个人在实际操作中最深的体会是读多队列架构的代码千万不要在一开始就钻到字段细节里。先把设计动机和整体分工刻在脑子里再回头去看字段每个成员的意义就会自动浮现。blk_mq_ctx负责提交隔离blk_mq_hw_ctx负责排队下发tag_set负责资源总控tag负责全链路索引这四句话就是整篇数据结构的骨架。下一篇我会接着讲控制路径上的核心机制包括请求分发、调度器如何与多队列协作、tag的实时状态追踪、超时与恢复流程以及我在实际场景中对这些机制做出的调优取舍。数据结构是静态的地图控制路径是动态的车流两者结合才算真正把blk-mq读完。
