3. 性能优化核心指标

在 Linux 驱动性能优化中，最忌讳“凭感觉调优”。驱动位于内核态，一次寄存器读写、一次 DMA 映射、一次中断处理，都会在系统层面放大为可观测的指标变化。因此，优化的第一步不是改代码，而是建立一套可量化、可复现、可对比的指标体系。本节围绕六个核心指标——吞吐量、延迟、CPU 占用率、内存带宽、I/O 等待与功耗，说明它们的物理含义、度量工具与采集方法，并给出指标之间的关联关系。

一、核心原理：六个指标构成驱动的性能画像

这六个指标并非彼此独立，而是相互制约。吞吐量衡量单位时间内完成的有效工作量，例如网卡驱动的 Mbps、块设备驱动的 IOPS 或 MB/s；延迟衡量单次操作从发起到完成的耗时，常用平均值、P50、P99 甚至 P999 描述；CPU 占用率反映驱动处理路径消耗的处理器时间，包括软中断、硬中断与内核线程；内存带宽描述单位时间内数据在 CPU、内存与设备之间的搬运量，DMA 是主要消耗者；I/O 等待体现任务因等待设备完成而阻塞的时间比例；功耗则关注驱动在活跃与空闲状态下的能耗表现，对移动与嵌入式场景尤为关键。

它们的关系可以概括为：提高吞吐量往往以增加延迟和 CPU 占用为代价；降低功耗常需要引入更深的空闲状态，从而抬高唤醒延迟；内存带宽不足会同时拖累吞吐量并推高 CPU 占用。因此，度量时必须同时采集多个指标，避免“按下葫芦浮起瓢”。

二、方法流程：从采集到归因的四步法

度量不是一次性动作，而是一条闭环流程。建议按以下四步执行：

1. 明确场景与基线：先确定测试负载（如 64B 小包、4K 随机读、大块顺序写），在未优化版本上采集基线数据，记录内核版本、CPU 频率策略、驱动参数。
2. 同步采集多指标：单指标容易误判。例如吞吐量下降可能源于 CPU 饱和，也可能源于 I/O 等待升高。应同时运行 mpstat、iostat、perf stat，并保证采样窗口一致。
3. 定位瓶颈层级：用 perf top 看热点函数，用 ftrace 看中断与调度延迟，用 blktrace 看块层排队，判断瓶颈在驱动、子系统还是硬件。
4. 验证与回归：修改后重复同一负载，对比 P99 延迟与 CPU 占用，确认没有引入新的抖动或功耗回退。

三、常用度量命令与参数

下面给出一组可直接复用的采集命令，覆盖六个指标中的主要项：

# 吞吐量：网络驱动
iperf3 -c 192.168.1.10 -t 30 -P 4

# 吞吐量与延迟：块设备驱动
fio --name=randread --ioengine=libaio --rw=randread \
    --bs=4k --iodepth=32 --runtime=30 --time_based \
    --latency_percentiles=99.99 --output-format=json

# CPU 占用：区分软中断与硬中断
mpstat -P ALL 1 10
perf stat -a -e cycles,instructions,cache-misses sleep 10

# 内存带宽：DMA 与缓存未命中
perf stat -e cycles,instructions,cache-references,cache-misses \
          -e uncore_imc_0/cas_count_read/ sleep 5

# I/O 等待与设备利用率
iostat -x 1 10
vmstat 1 10

# 功耗（Intel RAPL）
cat /sys/class/powercap/intel-rapl:0/energy_uj

其中 iostat -x 的 %util 与 await 是判断 I/O 等待的关键；perf stat 的 cache-misses 与 uncore 事件可间接反映内存带宽压力；RAPL 的 energy_uj 两次采样差值除以时间即为平均功耗。

四、案例场景：网卡驱动小包吞吐优化

某千兆网卡驱动在 64B 小包场景下吞吐仅 420 Mbps，P99 延迟 1.8 ms。采集数据发现：mpstat 显示单核 %soft 高达 78%，perf top 热点集中在 napi_poll 与 skb_copy，iostat 无异常，说明瓶颈在软中断处理与内存拷贝，而非 I/O 等待。优化措施包括：开启 NAPI 批量预算、使用 build_skb 减少一次拷贝、将中断亲和性绑定到独立核。优化后吞吐提升至 860 Mbps，P99 延迟降至 0.6 ms，软中断占用降至 41%。该案例说明：吞吐、延迟、CPU 占用必须联合观察，单看吞吐会误以为“只是带宽不够”。

五、指标对照清单