CANN Runtime 中 AUTO_USE_UC_MEMORY 环境变量详解算子数据搬移绕过 L2 Cache 的试验特性【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime本文以 CANN Runtime 的环境变量文档 AUTO_USE_UC_MEMORY 为主体完整讲解该变量的取值语义、默认行为与使用约束并结合仓库源码acl.cpp还原它在aclInit初始化流程中的真实生效路径从环境变量解析、内核启动填充函数kernel launch fill function注册到向算子写入 L2 Cache 偏移。读完本文你可以准确判断该变量是否适用于你的芯片型号理解默认开启、置 0 关闭的行为并知道如何在日志与单元测试层面验证配置是否生效。功能描述控制系统是否允许算子搬移数据不经过 L2 CacheAUTO_USE_UC_MEMORY控制系统是否允许算子搬移数据不经过 L2 Cache。这是该变量的核心语义开启后部分算子的数据搬移路径可以绕过 L2 Cache从而降低访存延迟、提升部分算子的执行性能。官方文档给出了明确的取值定义取值含义0或其他值否。所有算子搬移数据都必须经过 L2 Cache。1是。允许算子搬移数据可以不经过 L2 Cache具体是否经过 L2 Cache由算子 Kernel 代码中的逻辑决定。默认值为 1。这里有两点需要注意默认即开启该变量未设置时行为等同于1。如果想强制所有数据搬移必须走 L2 Cache需要显式设置AUTO_USE_UC_MEMORY0绕过 L2 Cache 是允许而非强制配置为1后是否真正绕过 L2 Cache 由算子自身的 Kernel 逻辑决定因此它是算子与运行时之间的一个协商开关而不是对数据路径的硬性改写。同时官方文档明确提示了收益与风险配置为 1 后部分算子性能可得到提升但可能存在AI Core Error 风险。须知本环境变量为试验特性后续版本可能会存在变更不支持应用于生产环境中。这意味着在正式生产部署前应在目标硬件上用自身模型充分验证正确性与稳定性不要仅凭性能提升就把它当作生产配置。配置示例在启动业务进程前设置环境变量即可关闭该特性export AUTO_USE_UC_MEMORY0由于默认值即为1因此该命令的典型用途是显式关闭。若环境未设置该变量行为与AUTO_USE_UC_MEMORY1一致。使用约束仅在 aclInit 初始化时读取文档给出的使用约束是在调用aclInit接口初始化时会触发读取该环境变量。换言之必须在进程完成 ACL 初始化之前设置好该变量运行中修改环境变量不会改变已初始化 Runtime 的行为变量只影响初始化阶段的内部配置注册后续 Kernel 的执行路径变化由算子侧决定。支持的型号文档按 NPU 型号声明了适用范围NPU 型号支持的产品系列310pAtlas 推理系列产品910bAtlas A2 训练系列产品 / Atlas A2 推理系列产品A3Atlas A3 训练系列产品 / Atlas A3 推理系列产品如果你的硬件不在此范围内即使设置了该变量也可能不产生预期效果——这一点与源码中的特性不支持分支相互印证见下文。源码级实现解析从环境变量到 L2 Cache 偏移写入以下实现细节均来自仓库源码可作为文档描述的落地证据。环境变量的枚举注册变量名与内部枚举 ID 的映射定义在两处枚举MM_ENV_AUTO_USE_UC_MEMORY 10000位于 mmpa_env_define.h归入 ACL 分组枚举 ID 与环境变量字符串AUTO_USE_UC_MEMORY的对照表位于 mmpa_linux_env.c。读取时使用的MM_SYS_GET_ENV宏定义在 mmpa_linux.h它优先调用可注入的mmSysGetEnv否则直接根据枚举名去掉MM_ENV_前缀后调用getenv。这也解释了为什么aclInit时设置环境变量即可被读到以及为什么在可测试场景下可以通过注入回调来模拟不同的环境变量值。解析逻辑未设置、空串、首字符为 1 均视为开启解析函数acl::IsEnableAutoUCMemeory()位于 acl.cppbool IsEnableAutoUCMemeory() { const char_t* autoUcMemory nullptr; MM_SYS_GET_ENV(MM_ENV_AUTO_USE_UC_MEMORY, autoUcMemory); // enable: env does not exist or set to 1 const bool enable ((autoUcMemory nullptr) || (strlen(autoUcMemory) 0UL) || (autoUcMemory[0] 1)); ACL_LOG_INFO(auto-uc-memory is %s., enable ? enabled : disabled); return enable; }可以归纳出三点行为环境变量不存在autoUcMemory nullptr→ 开启与默认值为 1的文档描述一致变量为空串→ 同样视为开启首字符为1→ 开启其他任何取值包括0、2等→ 关闭与文档0或其他值的语义完全吻合。初始化时日志会输出auto-uc-memory is enabled/disabled可作为配置是否被读取的快速验证手段。aclInit 阶段注册内核启动填充函数在aclInit的实现中acl.cpp只有IsEnableAutoUCMemeory()返回 true 时才会通过rtRegKernelLaunchFillFunc注册一个名为g_opSystemRunCfg的回调// register kernel launch fill function if (acl::IsEnableAutoUCMemeory()) { ACL_LOG_INFO(register kernel launch fill function in aclInit); const auto rtRegErr rtRegKernelLaunchFillFunc(g_opSystemRunCfg, acl::UpdateOpSystemRunCfg); if (rtRegErr ! RT_ERROR_NONE) { if (rtRegErr ACL_ERROR_RT_FEATURE_NOT_SUPPORT) { ACL_LOG_WARN(Cannot register kernel launch fill function, feature is not supported.); } else { ... return ACL_GET_ERRCODE_RTS(rtRegErr); } } }这里有一个值得注意的容错设计若底层返回ACL_ERROR_RT_FEATURE_NOT_SUPPORT特性不支持仅打印WARN日志而不让aclInit失败其他错误则向上返回初始化失败。从源码结构看这正对应了支持的型号清单之外的硬件——变量可以被设置但不受支持的芯片上该特性会被静默跳过不会导致进程启动失败。回调本体把 L2 Cache 偏移写进算子运行配置回调函数acl::UpdateOpSystemRunCfgacl.cpp是允许绕过 L2 Cache这一能力真正落地的地方。它在 Kernel 启动时被调用核心流程是校验入参cfgAddr非空、cfgLen sizeof(size_t)否则返回ACL_ERROR_RT_PARAM_INVALID通过rtGetDevice获取当前 device id调用rtGetL2CacheOffset(devId, offset)查询该设备的L2 Cache 偏移地址该调用若返回特性不支持则降级为 WARN将查询到的偏移值写入算子的系统运行配置缓冲*addr offset。uint64_t* addr static_castuint64_t*(cfgAddr); *addr offset; ACL_LOG_INFO(execute UpdateOpSystemRunCfg successfully, l2 cache offset is %lu, device id %d, offset, devId);也就是说Runtime 向算子交付的是该设备上 L2 Cache 的地址偏移这类系统信息算子 Kernel 侧据此判断数据搬移是否可以直接绕过 L2 Cache 进行——这与文档中具体是否经过 L2 Cache由算子 Kernel 代码中的逻辑决定的描述一致。aclFinalize 阶段对称地注销回调在aclFinalize中acl.cpp若该特性处于开启状态会调用rtUnRegKernelLaunchFillFunc(g_opSystemRunCfg)注销回调处理ACL_ERROR_RT_FEATURE_NOT_SUPPORT的方式与初始化时相同WARN 而非失败。注册与注销严格对称避免跨aclInit/aclFinalize生命周期泄漏回调状态。单元测试中的验证线索Runtime 侧的单元测试 rt_utest_profileapi.cc以及 910B 平台版本直接使用了相同的回调名g_opSystemRunCfg验证注册、查找与注销的完整生命周期包括注册后callbackMap_中存在该 key、注销后不再存在等断言。这说明该回调机制是 Runtime 的公开能力之一而非一次性临时逻辑也表明g_opSystemRunCfg这个键名在不同平台含 910B的测试中被一致使用。小结与使用建议默认行为不设置AUTO_USE_UC_MEMORY时等同于1开启显式export AUTO_USE_UC_MEMORY0可强制所有算子数据搬移经过 L2 Cache。生效时机仅在aclInit时读取一次须在初始化前设置可通过日志auto-uc-memory is enabled/disabled确认实际生效值。适用边界文档声明其为试验特性可能随版本变更不建议用于生产环境支持 Atlas 推理系列310p、Atlas A2910b、Atlas A3A3系列产品从源码结构看不受支持的芯片上注册回调会降级为 WARN 且不阻断初始化。权衡开启后部分算子性能可能提升但存在 AI Core Error 风险启用前建议先在目标硬件上完成正确性与稳定性验证。如需进一步理解该变量在整个 Runtime 环境变量体系中的位置可参考环境变量总览 env_vars/README。【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
CANN Runtime 中 AUTO_USE_UC_MEMORY 环境变量详解算子数据搬移绕过 L2 Cache 的试验特性【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime本文以 CANN Runtime 的环境变量文档 AUTO_USE_UC_MEMORY 为主体完整讲解该变量的取值语义、默认行为与使用约束并结合仓库源码acl.cpp还原它在aclInit初始化流程中的真实生效路径从环境变量解析、内核启动填充函数kernel launch fill function注册到向算子写入 L2 Cache 偏移。读完本文你可以准确判断该变量是否适用于你的芯片型号理解默认开启、置 0 关闭的行为并知道如何在日志与单元测试层面验证配置是否生效。功能描述控制系统是否允许算子搬移数据不经过 L2 CacheAUTO_USE_UC_MEMORY控制系统是否允许算子搬移数据不经过 L2 Cache。这是该变量的核心语义开启后部分算子的数据搬移路径可以绕过 L2 Cache从而降低访存延迟、提升部分算子的执行性能。官方文档给出了明确的取值定义取值含义0或其他值否。所有算子搬移数据都必须经过 L2 Cache。1是。允许算子搬移数据可以不经过 L2 Cache具体是否经过 L2 Cache由算子 Kernel 代码中的逻辑决定。默认值为 1。这里有两点需要注意默认即开启该变量未设置时行为等同于1。如果想强制所有数据搬移必须走 L2 Cache需要显式设置AUTO_USE_UC_MEMORY0绕过 L2 Cache 是允许而非强制配置为1后是否真正绕过 L2 Cache 由算子自身的 Kernel 逻辑决定因此它是算子与运行时之间的一个协商开关而不是对数据路径的硬性改写。同时官方文档明确提示了收益与风险配置为 1 后部分算子性能可得到提升但可能存在AI Core Error 风险。须知本环境变量为试验特性后续版本可能会存在变更不支持应用于生产环境中。这意味着在正式生产部署前应在目标硬件上用自身模型充分验证正确性与稳定性不要仅凭性能提升就把它当作生产配置。配置示例在启动业务进程前设置环境变量即可关闭该特性export AUTO_USE_UC_MEMORY0由于默认值即为1因此该命令的典型用途是显式关闭。若环境未设置该变量行为与AUTO_USE_UC_MEMORY1一致。使用约束仅在 aclInit 初始化时读取文档给出的使用约束是在调用aclInit接口初始化时会触发读取该环境变量。换言之必须在进程完成 ACL 初始化之前设置好该变量运行中修改环境变量不会改变已初始化 Runtime 的行为变量只影响初始化阶段的内部配置注册后续 Kernel 的执行路径变化由算子侧决定。支持的型号文档按 NPU 型号声明了适用范围NPU 型号支持的产品系列310pAtlas 推理系列产品910bAtlas A2 训练系列产品 / Atlas A2 推理系列产品A3Atlas A3 训练系列产品 / Atlas A3 推理系列产品如果你的硬件不在此范围内即使设置了该变量也可能不产生预期效果——这一点与源码中的特性不支持分支相互印证见下文。源码级实现解析从环境变量到 L2 Cache 偏移写入以下实现细节均来自仓库源码可作为文档描述的落地证据。环境变量的枚举注册变量名与内部枚举 ID 的映射定义在两处枚举MM_ENV_AUTO_USE_UC_MEMORY 10000位于 mmpa_env_define.h归入 ACL 分组枚举 ID 与环境变量字符串AUTO_USE_UC_MEMORY的对照表位于 mmpa_linux_env.c。读取时使用的MM_SYS_GET_ENV宏定义在 mmpa_linux.h它优先调用可注入的mmSysGetEnv否则直接根据枚举名去掉MM_ENV_前缀后调用getenv。这也解释了为什么aclInit时设置环境变量即可被读到以及为什么在可测试场景下可以通过注入回调来模拟不同的环境变量值。解析逻辑未设置、空串、首字符为 1 均视为开启解析函数acl::IsEnableAutoUCMemeory()位于 acl.cppbool IsEnableAutoUCMemeory() { const char_t* autoUcMemory nullptr; MM_SYS_GET_ENV(MM_ENV_AUTO_USE_UC_MEMORY, autoUcMemory); // enable: env does not exist or set to 1 const bool enable ((autoUcMemory nullptr) || (strlen(autoUcMemory) 0UL) || (autoUcMemory[0] 1)); ACL_LOG_INFO(auto-uc-memory is %s., enable ? enabled : disabled); return enable; }可以归纳出三点行为环境变量不存在autoUcMemory nullptr→ 开启与默认值为 1的文档描述一致变量为空串→ 同样视为开启首字符为1→ 开启其他任何取值包括0、2等→ 关闭与文档0或其他值的语义完全吻合。初始化时日志会输出auto-uc-memory is enabled/disabled可作为配置是否被读取的快速验证手段。aclInit 阶段注册内核启动填充函数在aclInit的实现中acl.cpp只有IsEnableAutoUCMemeory()返回 true 时才会通过rtRegKernelLaunchFillFunc注册一个名为g_opSystemRunCfg的回调// register kernel launch fill function if (acl::IsEnableAutoUCMemeory()) { ACL_LOG_INFO(register kernel launch fill function in aclInit); const auto rtRegErr rtRegKernelLaunchFillFunc(g_opSystemRunCfg, acl::UpdateOpSystemRunCfg); if (rtRegErr ! RT_ERROR_NONE) { if (rtRegErr ACL_ERROR_RT_FEATURE_NOT_SUPPORT) { ACL_LOG_WARN(Cannot register kernel launch fill function, feature is not supported.); } else { ... return ACL_GET_ERRCODE_RTS(rtRegErr); } } }这里有一个值得注意的容错设计若底层返回ACL_ERROR_RT_FEATURE_NOT_SUPPORT特性不支持仅打印WARN日志而不让aclInit失败其他错误则向上返回初始化失败。从源码结构看这正对应了支持的型号清单之外的硬件——变量可以被设置但不受支持的芯片上该特性会被静默跳过不会导致进程启动失败。回调本体把 L2 Cache 偏移写进算子运行配置回调函数acl::UpdateOpSystemRunCfgacl.cpp是允许绕过 L2 Cache这一能力真正落地的地方。它在 Kernel 启动时被调用核心流程是校验入参cfgAddr非空、cfgLen sizeof(size_t)否则返回ACL_ERROR_RT_PARAM_INVALID通过rtGetDevice获取当前 device id调用rtGetL2CacheOffset(devId, offset)查询该设备的L2 Cache 偏移地址该调用若返回特性不支持则降级为 WARN将查询到的偏移值写入算子的系统运行配置缓冲*addr offset。uint64_t* addr static_castuint64_t*(cfgAddr); *addr offset; ACL_LOG_INFO(execute UpdateOpSystemRunCfg successfully, l2 cache offset is %lu, device id %d, offset, devId);也就是说Runtime 向算子交付的是该设备上 L2 Cache 的地址偏移这类系统信息算子 Kernel 侧据此判断数据搬移是否可以直接绕过 L2 Cache 进行——这与文档中具体是否经过 L2 Cache由算子 Kernel 代码中的逻辑决定的描述一致。aclFinalize 阶段对称地注销回调在aclFinalize中acl.cpp若该特性处于开启状态会调用rtUnRegKernelLaunchFillFunc(g_opSystemRunCfg)注销回调处理ACL_ERROR_RT_FEATURE_NOT_SUPPORT的方式与初始化时相同WARN 而非失败。注册与注销严格对称避免跨aclInit/aclFinalize生命周期泄漏回调状态。单元测试中的验证线索Runtime 侧的单元测试 rt_utest_profileapi.cc以及 910B 平台版本直接使用了相同的回调名g_opSystemRunCfg验证注册、查找与注销的完整生命周期包括注册后callbackMap_中存在该 key、注销后不再存在等断言。这说明该回调机制是 Runtime 的公开能力之一而非一次性临时逻辑也表明g_opSystemRunCfg这个键名在不同平台含 910B的测试中被一致使用。小结与使用建议默认行为不设置AUTO_USE_UC_MEMORY时等同于1开启显式export AUTO_USE_UC_MEMORY0可强制所有算子数据搬移经过 L2 Cache。生效时机仅在aclInit时读取一次须在初始化前设置可通过日志auto-uc-memory is enabled/disabled确认实际生效值。适用边界文档声明其为试验特性可能随版本变更不建议用于生产环境支持 Atlas 推理系列310p、Atlas A2910b、Atlas A3A3系列产品从源码结构看不受支持的芯片上注册回调会降级为 WARN 且不阻断初始化。权衡开启后部分算子性能可能提升但存在 AI Core Error 风险启用前建议先在目标硬件上完成正确性与稳定性验证。如需进一步理解该变量在整个 Runtime 环境变量体系中的位置可参考环境变量总览 env_vars/README。【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
)
