在提交新问题之前，请确保您已经在社区中搜索过相关问题，并使用了社区中提供的资源/工具后，仍未找到满意的解决方式。

⚠️ 安全信息提醒：请仔细检查提供的文本内容，确保其不包含敏感数据信息，包括但不限于：

• API 令牌或密钥
• 密码或身份验证凭证
• 私有网址或接口地址
• 个人或机密数据
• ...

在分享配置信息或代码示例时，请将敏感信息脱敏处理，或使用 <TOKEN> 等占位符替代原有内容。

环境信息

通过 ldd 检查，CANN 8.5 和 9.1 两份测试程序分别链接各自版本的 libruntime.so、libascendcl.so 和 libmsprofiler.so，不存在“9.1 编译、8.5 运行时”的混用。

🐛 问题描述

问题描述

在 Atlas A3 服务器上使用 msprof --instr-profiling=on 采集 AI Vector/MTE 单算子 workload 时，msprof_*.json 的 biu_group 已正常生成，但以下四项指标在所有样本中均为 0：

• Bandwidth Read
• Bandwidth Write
• Latency Read
• Latency Write

该问题在以下场景均可复现：

1. 单卡本地 GM→UB MTE2 搬运；
2. 两张物理卡之间的 MTE remote load；

在两套CANN环境下都已复现同样问题：CANN 8.5 / CANN 9.1 （mindstudio-profiler 26.1.0）。

官方文档将 biu_group 定义为 AI Core/AI Vector 的 BIU 总线接口单元读写指令带宽和时延，并明确列出 Atlas A3 支持：

• CANN 9.1.0-beta.3：biu_group/aic_core_group/aiv_core_group
• CANN 9.0.0-beta.2：msprof instr-profiling 参数

采集过程中没有出现 unsupported 或解析失败错误，msprof 返回码为 0，也确实生成了大量 BIU 样本；但是派生的 BiuFlow 和更底层的 MonitorFlow/MonitorCycles 数值均为 0。希望确认这是当前芯片/驱动/固件的支持限制、workload 类型不匹配，还是 BIU 采集链路存在问题。

msprof 参数

两个场景都使用以下 BIU 采集参数：

--instr-profiling=on --instr-profiling-freq=300

完整命令形式为：

msprof \
  --output=<output_dir>/msprof_out \
  --application="<single_operator_application>" \
  --instr-profiling=on \
  --instr-profiling-freq=300

300 是文档允许范围 [300, 30000] 的最小采样间隔，用于尽量提高短单算子场景的样本覆盖率。由于文档说明 instr-profiling 与 --ai-core、--aic-metrics、--task-time 等参数互斥，本次 BIU run 没有同时加入这些互斥参数；普通 AIV PMU、HBM 和 LLC 数据使用相同 workload 的独立 profile 作为正向对照。

Workload 1：单卡本地 GM→UB

Workload 内容

运行 AI Vector kernel rma_operation_float_gm2ub_local，通过 MTE2 重复执行本地 GM→UB 搬运：

• dtype：float
• 元素数：2^15 = 32768
• 每次搬运数据量：32768 × 4 B = 131072 B
• block 数：1
• device：0
• loop count：100

复现命令

source /data/user/zfu472/cann-9.1.0/cann/set_env.sh

APP="/data/user/zfu472/agentic_projects/cann91_msprof_acc_pmu_biu_20260811/build_cann91/bin/ascendc_perftest \
  -t gm2ub_local -d float \
  --block-range 1 1 \
  --exponent-range 15 15 \
  --device1 0 --device2 1 \
  --loop-count 100 \
  --ub-size 16"

msprof \
  --output=<output_dir>/msprof_out \
  --application="$APP" \
  --instr-profiling=on \
  --instr-profiling-freq=300

结果

• msprof 返回码：0。
• 生成的 biu_perf.db 大小：30,138,368 B。
• BiuFlow 共 114,720 行，每种 flow 各 28,680 个样本。
• 四个 biu_group flow 的 min/max/avg/nonzero 均为 0/0/0/0。
• MonitorFlow 共 28,680 行，底层请求、时延、流量字段同样全部为 0。
• MonitorCycles 共 86,039 行，其中 Vector/Scalar/Cube/LSU cycle 字段也全部为 0。

Bandwidth Read : count=28680, min=0, max=0, avg=0, nonzero=0
Bandwidth Write: count=28680, min=0, max=0, avg=0, nonzero=0
Latency Read   : count=28680, min=0, max=0, avg=0, nonzero=0
Latency Write  : count=28680, min=0, max=0, avg=0, nonzero=0

使用同一 GM→UB workload 做独立普通 PMU/内存对照时：

• aiv_total_cycles=10,715,253,875；
• Mte2 执行时间为 364,058.073 µs，占 6.1%；
• device 0 HBM bandwidth 最大值为 293.63；
• LLC throughput 最大值为 120,924.23。

因此 kernel 确实执行了 MTE2 搬运，一般 profiler 数据链路也能观察到内存活动。

Workload 2：两张物理卡之间的 MTE remote load

Workload 内容

使用 4 个 SHMEM PE 映射到 device 0、1、2、3：

• initiator：PE0/device0，物理卡 0/die 0；
• target：PE2/device2，物理卡 1/die 0；
• 路径：device0 → device2，是真实跨物理卡路径，不是同卡跨 die；
• 操作：aclshmemx_mte_get_nbi 类型的 MTE remote load；
• payload：32768 B；
• block 数：1；
• warmup：10；
• loop count：500。

为了让 msprof 采集发起端，先裸启动 PE1、PE2、PE3，然后由 msprof --application 启动 PE0。应用参数如下：

p2p_engine_perftest \
  --pes 4 \
  --ipport tcp://127.0.0.1:<port> \
  --gnpus 4 \
  --fpe 0 --fnpu 0 \
  --initiator 0 \
  --targets 2 \
  --sizes 32768 \
  --engines mte \
  --ops load \
  --loop-count 500 \
  --warmup 10 \
  --mte-ub-kb 32 \
  --sdma-ub-bytes 64 \
  --output <output_dir>/p2p.csv

采集 PE0 的命令仍为：

msprof \
  --output=<output_dir>/msprof_out \
  --application="p2p_engine_perftest --pe-id 0 <上述公共参数>" \
  --instr-profiling=on \
  --instr-profiling-freq=300

Workload 正确性和性能旁证

engine=mte
op=load
initiator_pe=0
target_pe=2
path=cross_card
payload_bytes=32768
loop_count=500
latency_us=1.970360
bandwidth_GiB_s=15.488326
verify=pass

相同 workload 的独立普通 PMU/内存对照中：

• initiator AIV Mte2 执行时间为 2,290,236.164 µs，占 53.0%；
• Mte3 执行时间为 596,491.722 µs，占 13.8%；
• target device2 HBM bandwidth 最大值为 3,295.28；
• LLC throughput 最大值为 142,557.98。

因此跨卡 MTE load 确实完成，并产生了显著的 MTE、HBM 和 LLC 活动。

BIU 结果

• msprof 返回码：0。
• 完整采集和导出耗时约 208 秒。
• biu_perf.db 大小：239,767,552 B。
• BiuFlow：902,468 行。
• BiuCycles：4,063,590 行。
• MonitorCycles：677,265 行。
• MonitorFlow：225,617 行。
• 每种 Bandwidth/Latency Read/Write 各 225,617 个样本，全部为 0。

Bandwidth Read : count=225617, min=0, max=0, avg=0, nonzero=0
Bandwidth Write: count=225617, min=0, max=0, avg=0, nonzero=0
Latency Read   : count=225617, min=0, max=0, avg=0, nonzero=0
Latency Write  : count=225617, min=0, max=0, avg=0, nonzero=0

底层 MonitorFlow 以下字段的最大值和非零记录数也全部为 0：

stat_rcmd_num
stat_wcmd_num
stat_rlat_raw
stat_wlat_raw
stat_flux_rd
stat_flux_wr
stat_flux_rd_l2
stat_flux_wr_l2
l2_cache_hit

MonitorCycles 的以下字段同样全部为 0：

vector_cycles
scalar_cycles
cube_cycles
lsu1_cycles
lsu2_cycles
lsu3_cycles

CANN 8.5 对照结果

因此该现象不是 CANN 8.5 升级到 CANN 9.1 后出现的回归；在当前服务器的同一驱动/固件环境中，两个版本均可复现，升级到 9.1 也没有使 BIU 数据变为非零。

实际结果

1. msprof 正常退出，返回码为 0；
2. 未观察到 BIU unsupported、参数非法或 parser/calculator 失败信息；
3. msprof_*.json 中存在 biu_group；
4. biu_perf.db 中存在大量 BiuFlow/BiuCycles/MonitorFlow/MonitorCycles 行；
5. 所有 BIU 带宽、时延及其原始 monitor 字段均为 0；
6. workload 正确性通过，且独立正向对照中的 AIV Mte2/Mte3、HBM 和 LLC 数据非零。

预期结果

按照文档中“BIU 总线接口单元读取/写入指令时的带宽和时延”以及 Atlas A3 支持 biu_group 的描述，在持续 GM→UB MTE2 或跨卡 MTE load 执行期间，预期至少有与实际读事务相关的 BIU bandwidth/latency 字段出现非零样本。

如果 biu_group 实际不统计 MTE2/MTE3 数据路径，而只统计某种特定的 Scalar LSU、Cube、缓存路径或特定类型的官方单算子，也希望文档明确以下内容：

• 支持触发 BIU 的指令/执行单元和数据路径；
• Bandwidth Read/Write、Latency Read/Write 的单位和计算公式；
• Atlas A3 上可得到非零 BIU 数据的最小官方 workload；
• 自定义 Ascend C MIX_AIV 单算子是否属于支持范围。

已排除项

• 不是 workload 未执行：本地 kernel 正常完成；跨卡结果 verify=pass，有效带宽约 15.49 GiB/s。
• 不是采样时间太短：跨卡 case 产生 225,617 个 MonitorFlow 样本和约 240 MB DB。
• 不是采样间隔超范围：使用文档允许的最小值 --instr-profiling-freq=300。
• 不是参数被忽略或 profiler 直接失败：msprof rc=0，BIU parser/calculator 和相关数据表均已生成。
• 不是 timeline/GUI 显示问题：直接查询原始 SQLite 后，MonitorFlow/MonitorCycles 已全部为 0。
• 不是一般 profiler 链路或 MTE 活动缺失：相同 workload 的独立 AIV PMU、HBM、LLC 对照均非零。
• 不是 CANN 运行时混用：ldd 已确认 8.5/9.1 二进制分别链接对应版本库。

希望官方确认的问题

1. Atlas A3 / 当前 Ascend910 产品在 driver 25.5.1 上是否完整支持 biu_group？是否还有特定 firmware、driver 或 profiling component 的最低版本要求？
2. biu_group 是否应该统计 MTE2/MTE3 发起的 GM/UB 或远端 MTE load/store？如果不统计，准确的覆盖范围是什么？
3. 为什么 biu_perf.db 能生成大量样本，但原始 MonitorFlow/MonitorCycles payload 全为 0？这是否是已知的驱动、固件或产品事件映射问题？
4. 能否提供一个在 Atlas A3 上保证 Bandwidth Read/Write、Latency Read/Write 非零的官方最小复现 workload 和对应命令？

欢迎加入社区，感谢您对社区的贡献 🎉!