3. 测试环境搭建

UFS接口吞吐测试对环境的敏感度远高于普通存储读写测试。同一颗UFS器件,在不同主控平台、不同内核版本、不同固件配置下,顺序读吞吐可能相差30%以上。因此,环境搭建不是"插上板子跑个fio"这么简单,而是一套需要被记录、被锁定、被复现的工程化流程。本节围绕硬件平台选型、软件工具链、驱动与固件版本管理、环境校准方法四个维度展开。

一、核心原理:吞吐测试的瓶颈归属

吞吐测试的本质是"找瓶颈"。UFS链路理论带宽由M-PHY速率与Lane数决定,例如HS-G4 x2约为23.2Gbps(约2.9GB/s),HS-G5 x2约为46.4Gbps(约5.8GB/s)。但实测吞吐往往低于理论值,瓶颈可能出现在四个位置:UFS器件内部(NAND读带宽、FTL效率)、UFS控制器与PHY、主机控制器与DMA路径、以及主机CPU与软件栈。环境搭建的目标,就是让前三个环节尽量不成为瓶颈,从而真实测出器件能力。

UFS吞吐测试链路与瓶颈归属 主机CPU/软件栈 fio / 队列深度 中断亲和性 主机控制器 UFSHCI / DMA PCIe/SoC总线 M-PHY / UniPro HS-G4/G5 Lane数 / Gear UFS器件 NAND / FTL 缓存策略 常见瓶颈点 CPU单核跑满 · 中断未绑核 · DMA描述符不足 · PHY降速 · 器件热降频 · 固件限速策略 环境搭建目标 锁定主机侧变量 → 让瓶颈落在UFS器件 → 测得可复现的真实吞吐 记录平台/内核/驱动/固件/温度/队列深度,形成可追溯测试基线

二、硬件平台选型

硬件平台决定了测试上限。选型时优先关注以下几点:

  • SoC/主控支持的最高Gear与Lane数:若平台仅支持HS-G4 x1,则无法评估HS-G5 x2器件的真实性能,测试结论会被平台截断。
  • UFS插座与走线质量:测试夹具、转接板、飞线都会引入信号完整性问题,导致PHY降速或误码重传。优先使用原厂EVB或经SI验证的测试板。
  • CPU性能与核心数:高队列深度下,中断处理与协议栈开销会占用大量CPU。建议至少4核A76级别以上,并支持中断绑核。
  • 散热与供电:UFS在高负载下会触发热降频(Thermal Throttling),需保证器件表面温度可控,并记录测试时的温度曲线。
  • 可观测性:平台应支持UFS协议分析仪接入、PMIC电流采样、以及内核trace能力。

三、软件工具链

软件工具链负责产生负载、采集数据、解析协议。常用组合如下:

工具 用途 关键参数/说明
fio 生成顺序/随机读写负载 --rw=read --bs=128k --iodepth=32 --direct=1
iostat / blktrace 观察块层吞吐与延迟 iostat -x 1;blktrace -d /dev/sdX
ufs-utils / sg3_utils 发送UFS原生命令 sg_readcap、sg_raw、ufscli
UFS协议分析仪 抓取UniPro/M-PHY层报文 分析Gear切换、错误重传、命令队列
perf / ftrace 定位CPU与内核瓶颈 perf top;trace-cmd record -e ufs
热成像仪/温度传感器 监控器件温度 记录吞吐随温度变化曲线

四、驱动与固件版本管理

驱动与固件是吞吐测试中最容易被忽视、却最容易导致结果不可复现的变量。建议建立版本台账,每次测试前核对并记录:

# 查看内核与UFS驱动版本
uname -r
cat /sys/bus/platform/drivers/ufshcd/*/version 2>/dev/null
dmesg | grep -i ufs | head -30

# 查看UFS器件固件版本与健康状态
cat /sys/class/scsi_device/*/device/vendor
cat /sys/class/scsi_device/*/device/model
cat /sys/class/scsi_device/*/device/rev

# 查看当前Gear与Lane
cat /sys/kernel/debug/ufshcd/*/gear
cat /sys/kernel/debug/ufshcd/*/lane
注意:固件升级后必须重新做环境校准。部分厂商固件会调整缓存策略、GC触发阈值或热管理参数,导致吞吐曲线整体平移。若未记录固件版本,测试结论将无法归因。

五、环境校准方法

环境校准的目的是确认"当前环境没有明显瓶颈,且结果可复现"。推荐按以下流程执行:

  1. 空载基线:不挂载UFS,运行CPU与内存基准,确认平台自身无异常占用。
  2. 链路速率确认:读取当前Gear与Lane,确认已达到平台与器件协商的最高档位。
  3. 小负载预热:以低队列深度顺序读运行5分钟,使器件进入稳定热状态。
  4. 阶梯负载测试:从iodepth=1逐步提升到32/64/128,观察吞吐拐点,判断瓶颈位置。
  5. 重复性验证:同一配置连续运行3次,吞吐波动应小于5%;若波动过大,检查温度、后台任务与中断分布。
  6. 交叉验证:用协议分析仪核对链路层吞吐与块层吞吐是否一致,排除软件统计误差。
校准口诀:先锁平台,再锁版本,后锁温度;先看链路,再看块层,最后看器件。任何一项未锁定,吞吐数据都只能作为参考,不能作为结论。

六、案例与复盘:一次"虚高"的吞吐测试

某项目在HS-G4 x2平台上测得顺序读2.6GB/s,接近理论值,团队一度认为器件性能优秀。但交叉验证时发现:fio使用了--direct=0,数据实际命中了主机页缓存,并未真正落到UFS。改为--direct=1后,吞吐降至1.9GB/s,才是真实器件能力。

复盘结论有三点:第一,测试脚本必须强制direct=1并清空缓存;第二,吞吐数据必须与协议分析仪或器件内部计数器交叉验证;第三,环境校准记录中应包含"缓存状态"这一项。此后该项目将环境检查清单固化为自动化脚本,每次测试前自动核对内核版本、驱动版本、固件版本、Gear/Lane、温度与缓存状态,测试结果的可复现性显著提升。

本节要点:硬件选型决定测试上限,工具链决定观测能力,版本管理决定结果可复现性,环境校准决定结论可信度。四者缺一不可,且必须形成书面记录。