4、读写IO路径测试：单队列与多队列读写、4K对齐与非对齐IO、随机读写与顺序读写压力测试
各位工程师朋友，这一章咱们来聊聊读写IO路径测试。说实话，这是NVMe驱动兼容性测试里最硬核的部分之一。你想想看，驱动写得再好，如果IO路径上出了问题，那一切都是白搭。
我个人习惯把IO路径测试分成三个维度来考量：队列模式、对齐方式、访问模式。这三个维度组合起来，基本能覆盖掉90%以上的实际使用场景。我在项目中遇到过好几次，单队列跑得好好的，一上多队列就崩，最后查出来是中断亲和性没配好。
4.1 单队列与多队列读写测试
NVMe协议最核心的优势之一就是多队列。但说实话，很多嵌入式设备为了省资源，默认只开一个队列。这就导致了一个问题：单队列能过，不代表多队列也能过。
单队列测试要点：
- 确认队列深度（Queue Depth）是否支持最大配置，通常是1024
- 验证提交队列（SQ）和完成队列（CQ）的中断映射是否正确
- 检查单队列下的IOPS是否达到预期，别被驱动层的缓存给骗了
多队列测试要点：
- 每个队列对（Queue Pair）必须独立分配内存，不能共用
- 验证多队列下的负载均衡——说白了就是看中断是不是均匀分布在各个CPU核上
- 我建议至少测试2、4、8、16个队列，逐步增加，观察性能曲线
核心经验：多队列测试最容易翻车的地方是队列创建和销毁的时序。我曾经遇到过驱动在热插拔时，队列还没完全销毁就重新创建，导致DMA地址冲突，整个系统直接挂掉。
4.2 4K对齐与非对齐IO测试
嗯，这里要注意。4K对齐这个问题，很多新手容易忽略。你想想看，NVMe的LBA大小默认是512字节，但实际物理存储单元是4K。如果IO不按4K对齐，就会产生读改写（Read-Modify-Write）操作，性能直接腰斩。
对齐测试方案：
- 4K对齐IO：起始LBA是8的倍数（512B * 8 = 4KB），长度也是4K的整数倍
- 非对齐IO：起始LBA随机偏移1-7个扇区，长度随意
- 混合对齐：一部分对齐，一部分不对齐，模拟真实场景
我给大家一个简单的测试脚本思路：
// 伪代码示例：对齐与非对齐IO测试
for (offset = 0; offset < 8; offset++) {
for (size = 512; size <= 1MB; size *= 2) {
submit_io(lba = offset, length = size);
measure_latency_and_bandwidth();
}
}警告：非对齐IO在NVMe驱动中可能会触发额外的DMA分散/聚集操作。如果驱动实现有bug，轻则性能下降，重则数据损坏。我曾经在某个国产主控上遇到过，非对齐写入时DMA描述符链表的最后一个节点地址算错了，导致写入了隔壁用户的数据——这问题查了我整整三天。
4.3 随机读写与顺序读写压力测试
随机读写和顺序读写，说白了就是考验驱动对IO调度和缓存策略的处理能力。顺序读写相对简单，因为NVMe的硬件队列天然支持合并（Merge）。但随机读写就复杂多了，尤其是小IO随机读写。
顺序读写测试：
- 使用大块IO（128KB以上），验证带宽是否接近PCIe链路极限
- 测试连续读写100GB以上，观察性能是否衰减——这能暴露过热降频问题
- 我建议同时监控CPU占用率，别让驱动把CPU吃满了
随机读写测试：
- IO大小建议4KB、8KB、16KB，模拟数据库和日志场景
- 随机范围要覆盖全盘，别只在一个小区域里打转
- 混合读写比例：7:3（读多写少）和5:5（均衡），以及3:7（写多读少）
个人技巧：做随机读写压力测试时，我习惯同时跑4个线程，每个线程绑定不同的CPU核，队列也分开。这样能最大化暴露驱动在多核并发下的锁竞争问题。你想想看，如果驱动里有个全局锁，4个核同时抢，性能立马就现原形了。
4.4 综合压力测试方案
好了，前面三个维度都讲完了。但实际测试中，我建议把它们组合起来。下面是我常用的一个测试矩阵：
| 测试场景 | 队列数 | 对齐方式 | IO模式 | 持续时间 |
|---|---|---|---|---|
| 基础功能 | 1 | 4K对齐 | 顺序读写 | 30分钟 |
| 多队列压力 | 8 | 4K对齐 | 随机读写 | 2小时 |
| 非对齐攻击 | 4 | 非对齐 | 混合随机 | 4小时 |
| 极限压力 | 16 | 混合对齐 | 全随机 | 8小时 |
为什么要跑这么久？因为很多bug是概率性的。我曾经有一个案例，随机读写跑了6小时都没问题，第7小时突然出现一次IO超时。查到最后，是驱动里一个定时器的溢出处理没做好——这种问题，短时间测试根本发现不了。
最后提醒一句：压力测试过程中，一定要同时监控dmesg日志和硬件错误寄存器。NVMe设备有自己的错误日志（Error Log），很多驱动兼容性问题会先在这里留下痕迹。别等到系统崩了才去翻日志，那就晚了。