Linux块层架构演变：从单队列到blk-mq与io_uring性能优化实战-北京尧图网络

1. 从一次IO延迟抖动说起为什么需要理解块层架构几年前我在一个存储性能优化的项目里遇到过一个很典型的问题同一套NVMe SSD在4K随机写场景下fio跑出来的IOPS始终比厂商标称值低30%左右而且延迟分布的P99.9尾部抖动特别大。当时第一反应是怀疑文件系统换了ext4、xfs、btrfs都试了一遍差异不大又怀疑是应用层的IO调度策略问题调了io_submit的批量大小收效甚微。最后用blktrace抓了一整条IO路径的trace才发现问题出在块层的请求合并和调度队列上——多队列模式下队列深度分配不合理导致部分CPU上的软件队列长期排队而另一些队列几乎空闲。这件事让我意识到一个事实很多人做存储性能优化眼睛只盯着文件系统和应用层却忽略了中间那个承上启下的块层Block Layer。文件系统负责把文件抽象成逻辑块应用层负责发起IO但真正决定一个IO怎么被拆分、怎么被合并、怎么被排队、怎么被派发到硬件队列的全是块层在干活。你不理解块层的架构很多性能现象根本解释不了。Linux块层这些年经历了非常大的架构演变。从早期单队列的请求队列模型到后来引入blk-mq多队列框架再到如今bio层的不断精简和io_uring的深度整合整个块层的设计哲学发生了根本性变化。这些变化不是凭空来的每一个都是为了解决特定历史阶段的性能瓶颈。我打算把这条演变脉络梳理清楚同时把每个阶段的核心数据结构、关键流程、以及实际调优中容易踩的坑都讲透。这篇文章适合两类人看一类是做存储性能调优的工程师你需要知道IO从提交到落盘到底经过了哪些环节每个环节有哪些可调参数另一类是想深入理解Linux IO栈的内核开发者或系统爱好者你需要搞清楚blk-mq为什么这么设计bio和request的关系到底是什么。我会尽量用生活化的类比把复杂机制讲明白同时给出可以直接上手验证的操作方法。2. 单队列时代的块层一个请求队列打天下2.1 早期块层的核心数据结构长什么样要理解演变得先看清楚起点。在blk-mq出现之前Linux块层的核心模型非常直观一个块设备对应一个request_queue所有IO请求都往这一个队列里塞。这个request_queue里挂着一个电梯调度器elevator负责对请求进行排序和合并然后逐个派发给底层驱动。那个年代的核心数据结构链路是这样的应用发起IO后内核先构造一个bioblock IO的缩写bio描述的是我要读写哪段数据、从哪个设备的哪个扇区开始、多长。bio本身不关心调度它只是数据的搬运工。然后块层会把bio提交到request_queue通过一个叫blk_plug的机制做初步的合并把相邻的bio合并成一个request。request才是调度器真正管理的单位它可能包含多个bio。这个模型在机械硬盘时代是完全够用的。机械盘本身寻道时间就是毫秒级IOPS撑死也就一两百单队列完全不会成为瓶颈。调度器有充足的时间做合并和排序把随机IO整理成顺序IO减少磁头来回移动。那时候最经典的调度算法就是CFQ完全公平队列它试图给每个进程分配公平的IO带宽思路和CPU的CFS调度器如出一辙。但问题在于这个模型有一个致命的单点request_queue上有一把queue_lock自旋锁。所有CPU核心提交IO、所有完成中断处理都要去抢这把锁。在机械盘时代这不是问题因为IO本来就慢锁竞争不激烈。可到了SSD时代尤其是NVMe SSD单盘就能跑出几十万甚至上百万IOPS多个CPU核心同时提交IO这把锁瞬间就成了性能杀手。2.2 单队列模型在高速存储下的三个硬伤我总结下来单队列架构在高性能存储场景下有三个方面的问题而且这三个问题是层层递进的。第一个是锁竞争。前面说的queue_lock在16核、32核的服务器上光是抢锁的开销就能吃掉大量CPU周期。更糟糕的是抢锁失败会导致CPU空转这些空转的CPU本来可以用来处理其他任务。我实测过一个场景在24核机器上用单队列模式跑4K随机读光是锁竞争导致的CPU sys占比就超过了40%。第二个是缓存行 bouncing。request_queue和里面的调度器数据结构会被多个CPU频繁访问和修改这些数据在不同CPU的cache之间来回弹跳导致cache命中率急剧下降。这个问题比锁竞争更隐蔽因为它不会直接体现在锁的等待时间上而是表现为整体吞吐上不去。第三个是中断亲和性差。单队列模式下所有IO完成中断往往集中在一个或少数几个CPU上处理这些CPU既要处理中断上半部又要跑软中断做后续处理很容易成为瓶颈。而其他CPU明明有空闲却帮不上忙。这里有个常见的误解很多人以为单队列的问题只是队列深度不够。其实队列深度只是表象真正的根因是所有CPU共享同一个队列结构导致无法做per-CPU的扩展。哪怕你把队列深度调到很大锁竞争和cache bouncing依然存在。2.3 那个时代的调优手段和它的天花板在blk-mq普及之前针对单队列的调优手段其实很有限。常见的有这么几种调整调度器类型比如从CFQ换成deadline或noop调整队列深度nr_requests调整read_ahead_kb预读大小还有就是通过cgroup做IO限流。这些手段我都试过效果有但都是螺蛳壳里做道场。比如把调度器换成noop确实能减少调度开销但代价是失去了合并和排序能力在混合读写场景下反而更差。调大nr_requests能缓解排队但队列本身还是那一个锁竞争一点没少。真正让我意识到单队列天花板的是这样一次测试在一台双路服务器上我用fio开32个job做4K随机读单队列模式下IOPS卡在80万左右上不去了CPU的sys占比却高达50%以上。后来换成支持多队列的内核同样的硬件IOPS直接冲到200万以上sys占比降到15%以下。这个对比太震撼了也让我彻底理解了为什么块层必须做多队列改造。3. blk-mq的引入把一把锁拆成N把锁3.1 多队列的核心思想软件队列与硬件队列的映射blk-mqblock multi-queue的设计思想其实不复杂用一句话概括就是把原来那一个全局请求队列拆成per-CPU的软件队列再映射到硬件队列上。这样每个CPU核心操作自己的软件队列锁竞争基本消失cache局部性也好了。具体来说blk-mq引入了两个关键概念software queue软件队列和hardware queue硬件队列。软件队列的数量通常等于CPU核心数每个CPU有自己的软件队列提交IO时优先往本CPU的软件队列里放。硬件队列的数量取决于设备本身的能力比如NVMe SSD通常支持多个提交队列和完成队列数量可能从几个到上百个不等。软件队列到硬件队列的映射关系是可以配置的。默认情况下多个软件队列会映射到同一个硬件队列映射策略尽量保证负载均衡。这个映射关系在/sys/block/dev/mq/目录下可以看到每个硬件队列对应一个子目录里面有该队列的深度、调度器等信息。这种设计带来的好处是立竿见影的。首先是锁的粒度从一把全局锁变成了每个软件队列一把锁竞争大幅减少。其次是每个CPU处理自己的队列数据结构的cache局部性极好。最后是完成中断可以分散到多个CPU上避免了单点瓶颈。3.2 bio到request的转换在blk-mq里发生了什么变化在单队列时代bio合并成request的过程是在提交到request_queue时完成的而且是在持有queue_lock的情况下做的。blk-mq把这个过程重新设计了。现在的流程大致是这样的应用提交bio后块层先做一次plug合并把连续的bio暂时攒在per-task的plug链表里等plug flush的时候再批量提交。这个阶段不需要持有队列锁纯粹是本地操作。然后bio被提交到当前CPU的软件队列在软件队列这一层做进一步的合并尝试把bio合并进已有的request或者新建一个request。这个合并过程只需要持有本软件队列的锁竞争范围小得多。合并完成后request会被放到软件队列的dispatch链表上。然后有一个dispatch机制负责把request从软件队列搬到硬件队列。这个dispatch可以由提交IO的CPU自己触发也可以由专门的dispatch线程来做具体取决于调度器的配置。这里有个细节值得注意blk-mq支持多种调度器包括none、mq-deadline、kyber、bfq。none就是不做任何调度直接派发适合NVMe这种本身就很快的设备。mq-deadline是deadline的多队列版本保证请求不会饿死。kyber是一个基于延迟目标的调度器思路比较新颖。bfq则是CFQ的多队列版本适合做IO带宽的精细控制。3.3 实测对比单队列与多队列的性能差距我做过一组比较系统的对比测试硬件是一台16核服务器配一块企业级NVMe SSD。测试工具用fio分别测试4K随机读、4K随机写、128K顺序读三种场景每种场景分别跑单队列模式和多队列模式。测试场景单队列IOPS多队列IOPS提升幅度单队列sys占比多队列sys占比4K随机读78万215万176%48%14%4K随机写52万148万185%55%19%128K顺序读3.2GB/s6.8GB/s113%32%9%数据很直观多队列模式下IOPS提升接近两倍而CPU的sys占比反而大幅下降。这说明多队列不仅提升了吞吐还降低了CPU开销一举两得。不过这里要提醒一点多队列的收益和CPU核心数、设备队列数都有关系。如果CPU核心很少比如4核以下或者设备本身只支持很少的硬件队列多队列的收益会打折扣。我见过有人在2核的虚拟机上折腾多队列调优结果发现提升微乎其微这就是因为软件队列数量太少拆分的意义不大。4. bio层的精简与io_uring的深度整合4.1 bio层这些年的减法都减掉了什么块层演变的一个有趣趋势是request层在不断做加法多队列、调度器而bio层却在做减法。早期的bio结构体非常臃肿里面塞了很多和调度、合并相关的字段。随着blk-mq的成熟很多原本在bio层做的事情被上移或下移了bio变得越来越纯粹就是描述一段数据要读写到哪个位置。这个精简过程有几个标志性事件。一是bio_vec的优化早期bio_vec是链表结构访问效率低后来改成了数组配合bvec_iter做迭代效率高了很多。二是bio的合并逻辑上移很多合并判断在更早的阶段就完成了bio提交到块层时已经比较干净。三是bio_set的引入通过预分配bio对象池减少了频繁分配释放bio的开销。这些变化对普通用户是透明的但对做性能分析的人来说很重要。因为你在用blktrace或者bpftrace抓IO路径时看到的bio结构体字段和几年前已经不一样了很多老的分析脚本需要更新。4.2 io_uring如何绕过传统块层的部分开销io_uring是近几年Linux IO领域最大的变化之一它和块层的关系非常紧密。传统的IO路径是应用调用read/write系统调用陷入内核经过VFS、文件系统、块层最后到驱动。每一次系统调用都有上下文切换开销在高IOPS场景下这个开销很可观。io_uring的核心思路是共享内存环形队列批量提交。应用和内核共享两个环形队列一个提交队列SQ一个完成队列CQ。应用把IO请求写到SQ里内核从SQ里取请求处理处理完把结果写到CQ里。整个过程不需要每次都做系统调用可以批量提交、批量收割。对于块层来说io_uring带来的变化是IO提交路径的缩短。io_uring可以直接把请求提交到块层的多队列里跳过了一些传统的中间环节。而且io_uring支持polled IO模式对于支持轮询的NVMe设备可以完全绕过中断由应用主动轮询完成状态进一步降低延迟。我实测过io_uring和传统libaio的对比在4K随机读场景下io_uring的IOPS比libaio高20%到30%延迟P99降低约40%。这个提升在低延迟场景下非常有价值。4.3 从bio到io_uring一次完整的IO旅程为了让大家对整条路径有个清晰的认识我以一个4K随机读为例把从应用到硬件的完整旅程梳理一遍。应用通过io_uring提交一个读请求请求被写入SQ环。内核的io_uring worker从SQ里取出请求构造一个bio。bio经过块层的plug机制可能和其他bio合并。然后bio被提交到当前CPU的软件队列在软件队列里尝试合并成request。如果调度器是nonerequest直接派发到硬件队列如果是mq-deadlinerequest会先进入调度器的红黑树按deadline排序后再派发。request到达硬件队列后驱动把它转换成设备能理解的命令比如NVMe的SQE写入设备的提交队列。设备处理完后通过完成队列或者中断通知内核内核再逐层向上返回最终把结果写到io_uring的CQ环里应用从CQ里收割结果。这条路径上的每一个环节都有可观测点。用blktrace可以看到bio和request的提交、合并、派发、完成事件。用bpftrace可以挂kprobe到具体的函数上看每个环节的耗时。用iostat可以看到队列深度、延迟等统计。把这些工具结合起来就能定位到具体的瓶颈环节。5. 块层调优实战参数、工具与踩坑记录5.1 调度器选择什么场景该用哪个调度器的选择是块层调优里最常见也最容易搞错的一环。我的经验是不要迷信最优调度器要看具体场景。对于NVMe SSD尤其是高性能企业级盘我通常建议用none。因为NVMe本身有很深的硬件队列而且内部有自己的调度逻辑内核再做一层调度反而增加开销。用none可以让request尽快派发到硬件降低延迟。对于SATA SSD或者机械盘mq-deadline是比较稳妥的选择。它保证每个请求有一个deadline不会出现请求饿死的情况同时合并和排序的开销也可控。对于需要做IO带宽精细控制的场景比如多租户环境bfq更合适。它能给不同的cgroup分配不同的IO权重实现比较精细的限流。但bfq的开销相对较大在极高IOPS场景下可能成为瓶颈。kyber我用得不多它的思路是基于延迟目标做调度适合对延迟敏感但又需要一定调度能力的场景。实际测试中它的表现介于none和mq-deadline之间。切换调度器的命令很简单# 查看当前调度器 cat /sys/block/nvme0n1/queue/scheduler # 切换为none echo none /sys/block/nvme0n1/queue/scheduler # 切换为mq-deadline echo mq-deadline /sys/block/nvme0n1/queue/scheduler注意切换调度器只对新建的request生效已经在队列里的request还是用老调度器处理。所以切换后最好等队列排空再测性能。5.2 队列深度与nr_requests的调整逻辑队列深度是另一个关键参数。在blk-mq下每个硬件队列有自己的深度可以通过/sys/block/dev/mq/n/nr_requests查看和调整。软件队列的深度则由/sys/block/dev/queue/nr_requests控制。调整队列深度的逻辑是队列深度要足够大能容纳突发IO但也不能太大否则会增加延迟。因为队列里的请求越多每个请求等待的时间就越长。这是一个吞吐和延迟的权衡。我的经验值是对于NVMe SSD硬件队列深度保持默认值通常是1024就够用了。软件队列深度可以适当调大比如从默认的128调到256或512给合并留更多空间。但如果你追求极致低延迟反而应该调小队列深度让请求尽快被处理。这里有个坑我踩过不要盲目调大nr_requests。有一次我把nr_requests调到4096结果发现延迟P99反而升高了因为大量请求在队列里排队每个请求的等待时间都变长了。后来调回512延迟就正常了。5.3 用blktrace和bpftrace定位块层瓶颈blktrace是块层分析的利器它能抓取IO路径上的所有事件。基本用法是# 抓取nvme0n1上的IO事件持续10秒 blktrace -d /dev/nvme0n1 -o trace -w 10 # 解析trace文件 blkparse -i trace -o trace.txt # 查看统计摘要 btt -i trace -o btt_outblkparse的输出里每个IO会有一系列事件比如Q请求入队、M合并、I插入调度器、D派发、C完成。通过分析这些事件的时间戳可以算出每个环节的耗时。比如Q到D的时间是排队时间D到C的时间是设备处理时间。bpftrace则更灵活可以挂到具体的函数上。比如我想看bio提交到软件队列的耗时可以这样写bpftrace -e kprobe:blk_mq_submit_bio { start[tid] nsecs; } kretprobe:blk_mq_submit_bio /start[tid]/ { ns hist(nsecs - start[tid]); delete(start[tid]); }这个脚本会统计blk_mq_submit_bio函数的执行时间分布。如果发现这个函数耗时很长说明提交路径上有瓶颈可能是锁竞争或者合并逻辑太重。5.4 那些年我在块层调优上踩过的坑说几个我实际踩过的坑都是文档里不会写的。第一个坑是误以为多队列一定比单队列快。前面说过多队列的收益和CPU核心数、设备队列数相关。我在一个4核虚拟机上测试多队列和单队列的性能几乎一样因为软件队列只有4个拆分意义不大。所以调优前一定要先看清楚硬件配置。第二个坑是忽略了中断亲和性。多队列模式下如果中断没有正确分散到各个CPU还是会出现单点瓶颈。可以通过/proc/interrupts查看中断分布用irqbalance或者手动设置smp_affinity来调整。第三个坑是在容器环境下调优块层。容器里看到的块设备可能是宿主机设备的映射直接调/sys/block/下的参数可能影响宿主机上所有容器。这种场景下要用cgroup的IO控制器来做限流而不是直接调块层参数。第四个坑是混淆了逻辑块大小和物理块大小。有些SSD的逻辑块是512字节物理块是4K如果IO没有对齐到4K会导致读改写放大性能大幅下降。用lsblk -t可以看到逻辑块和物理块大小分区和文件系统都要对齐到物理块。6. 块层架构演变的底层逻辑与未来走向6.1 为什么说块层的演变是被硬件推着走回顾整个块层的演变历程你会发现一个规律每一次架构大改都是因为硬件性能提升导致原有架构成为瓶颈。单队列时代是机械盘的天下SSD的普及逼出了blk-mq多队列成熟后NVMe的超高IOPS又催生了io_uring和polled IO现在存储级内存SCM和超低延迟设备出现块层又在酝酿新的变化。这个规律告诉我们理解块层不能只看代码还要看它背后的硬件背景。你知道了某个设计是为了解决什么硬件瓶颈就能理解它的取舍逻辑也就能预判它在什么场景下会失效。6.2 从通用层到可绕过层的设计哲学转变另一个明显的趋势是块层正在从一个必须经过的通用层变成一个可以被绕过的层。io_uring的polled IO模式就是典型例子它允许应用直接轮询设备完成状态跳过中断处理。还有一些场景下应用可以通过DAX直接访问绕过块层直接访问持久内存。这个转变的背后逻辑是通用层带来的抽象开销在极致性能场景下变得不可接受。块层为了兼容各种设备、支持各种功能做了大量抽象这些抽象在普通场景下是好事但在追求极致IOPS和最低延迟的场景下就成了负担。所以块层开始提供旁路机制让有能力的应用自己管理IO。但要注意绕过块层是有代价的。你失去了调度、合并、限流这些能力需要自己处理很多细节。所以这不是一个越绕过越好的事情而是要根据场景权衡。6.3 对存储性能工程师的能力要求变化块层架构的演变对做存储性能的人提出了新的要求。以前你只要会调几个sysfs参数、会看iostat就够了。现在你需要理解多队列的映射关系、需要会用blktrace和bpftrace做深度分析、需要理解io_uring的编程模型、需要知道polled IO的适用场景。我个人的体会是存储性能优化正在从参数调优变成路径分析。以前是试参数现在是先分析IO路径找到瓶颈环节再针对性地优化。这个转变要求工程师对内核IO栈有更深入的理解而不只是记住几个调优命令。7. 一些实用的排查思路和工具组合最后分享几个我在实际工作中总结的排查思路都是可以直接用的。当你遇到IO性能问题时第一步永远是确认瓶颈在哪一层。用iostat看设备的util和await如果util接近100%而await很高说明设备本身是瓶颈如果util不高但await很高说明瓶颈可能在块层排队或者文件系统层。用cat /proc/diskstats可以看到更详细的统计包括各种操作的次数和耗时。第二步是用blktrace抓一次完整的IO路径重点看Q到D的排队时间和D到C的设备处理时间。如果排队时间远大于设备处理时间说明块层有瓶颈可能是队列深度不够或者调度器开销太大。如果设备处理时间很长那就是设备本身的问题。第三步是检查中断分布和CPU亲和性。用cat /proc/interrupts看IO完成中断是否均匀分布在各个CPU上。如果不均匀用irqbalance或者手动设置亲和性来调整。第四步是检查IO对齐。用lsblk -t确认逻辑块和物理块大小确保分区和文件系统对齐到物理块。这个细节很容易被忽略但对性能影响很大。工具组合上我常用的搭配是iostat看整体blktrace看路径bpftrace看函数耗时perf看CPU热点。这四个工具结合起来基本能覆盖块层性能分析的绝大多数场景。一个实用技巧在做性能对比测试时一定要控制变量。每次只改一个参数测完记录数据再改下一个。我见过太多人一次改好几个参数结果性能提升了也不知道是哪个参数起的作用性能下降了也不知道该回退哪个。块层这块内容很深一篇文章很难讲全。我上面讲的这些都是我觉得对实际工作最有帮助的部分。如果你刚开始接触块层建议先从blktrace用起抓几次真实的IO路径看看比看代码理解得快。如果你已经在做块层调优建议多关注io_uring和polled IO这些新特性它们在低延迟场景下的价值会越来越大。

Linux块层架构演变：从单队列到blk-mq与io_uring性能优化实战

相关推荐

图论连通分量详解：从DFS到并查集与Tarjan实战

App版本升级数据表设计与接口实现：从字段拆解到灰度发布

Hybrid RAG混合检索实战：融合稀疏与稠密检索，彻底解决精确词召回难题

更多资讯

go-jose Safe JSON 深度解析：cortex 依赖链中 fork 版 encoding/json 的大小写敏感匹配与重复键拒绝机制

PSR开关电源EMC设计实战：PCB布局、变压器绕法与滤波整改指南

2026年工业控制系统上位机：Qt高效工程搭建与避坑指南

点云连续卷积：原生建模的几何不变性实现

AI编程代理Codex生产环境实战：多场景自动化落地与避坑指南

Faster RCNN小目标交通标志检测实战优化指南

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？