| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
revert: restore ascend950 cce_file directory name Co-authored-by: daijinling<daijinling2@huawei.com> # message auto-generated for no-merge-commit merge: !1481 merge refactor/soc_version_20260312_part_delete into master revert: restore ascend950 cce_file directory name Created-by: daijinling Commit-by: daijinling Merged-by: cann-robot Description: ## 描述 本次改动回退了最近一次将 src/runtime/core/cce_file/ascend950 重命名为 src/runtime/core/cce_file/dav_3510 的修改。 改动原因： 当前代码和产物命名仍以 ascend950 为主，直接重命名为 dav_3510 后会造成目录命名与现有实现、安装路径不一致，不利于后续维护和使用。 改动内容： 1. 将 src/runtime/core/cce_file/dav_3510 恢复为 src/runtime/core/cce_file/ascend950 2. 将对应 CMakeLists.txt 中的安装路径从 lib/dav_3510 恢复为 lib/ascend950 3. 以单独 commit 方式提交本次回退，避免与其他改动混杂 ## 关联的Issue https://gitcode.com/cann/runtime/issues/316 ## 测试 本次改动仅涉及目录名和安装路径恢复，未修改运行时逻辑。 ## 文档更新 无 ## 类型标签 - [ ] Bug修复 - [ ] 新特性 - [ ] 性能优化 - [ ] 文档更新 - [x] 其他，请描述：回退 ascend950 -> dav_3510 目录重命名 See merge request: cann/runtime!1481 | 5 个月前 | |
【PR】:并发扫描问题修改 Co-authored-by: qymspace<qiuyaming@huawei.com> # message auto-generated for no-merge-commit merge: !5101 merge tmp/concurrency-fixes-5-6-7 into master 【PR】:并发扫描问题修改 Created-by: qymspace Commit-by: qymspace Merged-by: cann-robot Description: # Pull Request ## 描述 本 PR 修复 Runtime 中三处并发数据竞争（对应 #5084 中的问题 5/6/7），每个修复独立成 commit、互不依赖，可单独合入或 cherry-pick。三处问题均为多线程对共享数据的无保护读写（C++ 数据竞争 / UB），修复不改变任何对外接口、ABI 及既有语义边界。 ### 1. 修复算子异常回调注册并发竞争 - **问题**： aclrtBinarySetExceptionCallback 分别写入 callback 和 userData 两个普通指针，异常通知线程（OpTaskFailCallbackNotify）也分别读取。并发重复注册存在数据竞争，并可能以"新 callback + 旧 userData"的撕裂组合调用用户回调。 - **方案**：Program 新增专用互斥量保护二元组；注册路径在同一临界区完成成对替换（ExchangeOpExceptionCallback）；通知路径锁内取得一致快照后释放锁，再调用用户回调，避免持锁执行用户代码及回调重入死锁。 - **语义保持**：重复注册仍无条件覆盖并打印 INFO 日志；userData 生命周期仍由调用方保证。 ### 2. 修复 profiling 开关数据并发读写 - **问题**：ProfCtrlCallbackManager::SaveProfSwitchData 无锁更新 switchData_ 与 switchIsSet_，NotifyProfInfo 与 GetSwitchData 可同时读取，存在数据竞争；通知回调还可能收到由两次配置拼接而成的撕裂结构。 - **方案**：新增独立互斥量保护开关状态；写入路径在同一临界区更新完整结构与有效标志；通知路径锁内生成一致快照、解锁后再调用外部回调；查询路径同锁读取。同时为成员补充默认初始化，消除首次保存前读取未初始化内存的问题。 ### 3. 修复 Bitmap 分配元数据并发竞争 - **问题**：Bitmap 的 allocedCnt_ 与 lastAllocIdx_ 为普通整数，并发 AllocId/FreeId 产生数据竞争及计数丢更新，高水位判断可能出错；较大分配范围留下的扫描起点可能越过后续较小分配的上限，造成超限分配（AllocId(64) 分配出 id ≥ 64）。 - **方案**：计数与扫描提示改为 Atomic；分配成功后原子加计数；释放通过 CAS 循环饱和减一（保留 OccupyId 不计数的既有语义）；扫描起点按当前位图上限取模归一化。 - **范围说明**：freeBitmap_ 指针首次发布与位元素访问的内存序同步属独立问题，本 PR 不扩展（见 commit message）。 ## 变更类型 - [x] 🐛 Bug 修复 ## 关联的Issue 无。如有对应 issue，请在右侧"关联Issue"部分补充链接并勾选"合并后关闭已关联的 Issue"。 ## 如何测试 1. 按仓内 UT 构建流程编译 runtime_utest 与 runtime_utest_api 目标； 2. 运行本 PR 新增的并发回归用例： - ApiExceptionTest.ConcurrentExceptionCallbackPairIsConsistent（双写者 + 读者校验 callback/userData 二元组一致性，混合配对即失败） - ProfileApiTest.ConcurrentProfSwitchSnapshotIsConsistent（并发切换开关时，通知回调收到的 rtProfCommandHandle_t 快照必须是完整一致的配置） - DriverTest.bitmap_concurrent_allocation_metadata（8 线程并发分配/释放 512 个 id，校验 id 唯一性与计数终值一致性） - DriverTest.bitmap_normalizes_allocation_hint_for_smaller_limit（128 容量分配 65 个 id 后以 64 上限申请应返回 -1，回归扫描起点归一化） 3. 回归运行相关既有套件：ApiExceptionTest.*、ProfileApiTest.*、DriverTest.*。 自测结果：上述新增用例全部通过，并发用例重复执行 20 次无抖动；相关套件全量回归通过与基线一致，无新增失败。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 - 变更均为内部实现（src/runtime/core 与内部头文件），不涉及 include/ 对外边界，无 API/ABI 兼容性影响，故无需文档同步。 See merge request: cann/runtime!5101 | 1 天前 | |
refactor: 优化查询与读取接口职责归属(#990) Co-authored-by: jia_shaoyang<jiashaoyang@huawei.com> # message auto-generated for no-merge-commit merge: !5027 merge context_refactor into master refactor: 优化查询与读取接口职责归属(#990) Created-by: jia_shaoyang Commit-by: jia_shaoyang Merged-by: cann-robot Description: # Pull Request ## 描述 本 PR 优化 Runtime 查询、读取及无状态辅助接口的职责归属，移除 Context 对领域逻辑的透传和实现依赖： 1. GetNotifyAddress、GetDevArgsAddr、CopyTilingTabToDev 分别收敛到 Notify、Stream 和 Program。 2. GetStackBuffer、GetExceptionRegInfo 迁移到 Device Debug，保留 Stars 与 StarsV2 的平台差异。 3. SetMemcpyDesc 迁移到 Memcpy 平台实现，保留 Stars 与 StarsV2 descriptor 处理差异。 4. CheckMemAlign 迁移为 Memory Common 无状态函数。 5. 删除旧 Context 成员和转发实现，并同步调整平台构建挂载及相关单元测试。 重构保持公开 API、wrapper 参数校验、默认流选择、日志及错误返回顺序不变，同时保留 Stars 与 David 的既有行为差异。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 关联并在合入后关闭 #990。 ## 如何测试 1. Release 全量编译、链接和 Runtime run 包生成通过。 2. 六个相关 UT 目标共 93 个定向 LLT 全部通过：runtime_utest 16 个、runtime_utest_api 18 个、runtime_utest_api_910B 21 个、runtime_utest_task_910B 12 个、runtime_utest_api_david 18 个、runtime_utest_task_david 8 个。 3. 在 Ascend910B3 上对清单中的 41 个现有 HLT 候选执行基线门禁：基线 33 个框架 PASS（含 5 个平台跳过）、7 个 FAIL、1 个 UNAVAILABLE；28 个基线可比用例在当前包上 28/28 PASS，0 FAIL、0 TIMEOUT。 4. git diff --check 通过。 HLT 覆盖边界：GetDevArgsAddr 尚无已编包专项用例；Notify 的两个候选在 910B 跳过；CheckMemAlign 本次完成 INT8 分支回归，FP32/FP16 候选未通过基线门禁；David/950 及其他非 910B 平台专项未在本轮执行。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [ ] 我已更新了相关的文档（本次不涉及对外文档变更） - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 See merge request: cann/runtime!5027 | 1 天前 | |
【PR】:并发扫描问题修改 Co-authored-by: qymspace<qiuyaming@huawei.com> # message auto-generated for no-merge-commit merge: !5101 merge tmp/concurrency-fixes-5-6-7 into master 【PR】:并发扫描问题修改 Created-by: qymspace Commit-by: qymspace Merged-by: cann-robot Description: # Pull Request ## 描述 本 PR 修复 Runtime 中三处并发数据竞争（对应 #5084 中的问题 5/6/7），每个修复独立成 commit、互不依赖，可单独合入或 cherry-pick。三处问题均为多线程对共享数据的无保护读写（C++ 数据竞争 / UB），修复不改变任何对外接口、ABI 及既有语义边界。 ### 1. 修复算子异常回调注册并发竞争 - **问题**： aclrtBinarySetExceptionCallback 分别写入 callback 和 userData 两个普通指针，异常通知线程（OpTaskFailCallbackNotify）也分别读取。并发重复注册存在数据竞争，并可能以"新 callback + 旧 userData"的撕裂组合调用用户回调。 - **方案**：Program 新增专用互斥量保护二元组；注册路径在同一临界区完成成对替换（ExchangeOpExceptionCallback）；通知路径锁内取得一致快照后释放锁，再调用用户回调，避免持锁执行用户代码及回调重入死锁。 - **语义保持**：重复注册仍无条件覆盖并打印 INFO 日志；userData 生命周期仍由调用方保证。 ### 2. 修复 profiling 开关数据并发读写 - **问题**：ProfCtrlCallbackManager::SaveProfSwitchData 无锁更新 switchData_ 与 switchIsSet_，NotifyProfInfo 与 GetSwitchData 可同时读取，存在数据竞争；通知回调还可能收到由两次配置拼接而成的撕裂结构。 - **方案**：新增独立互斥量保护开关状态；写入路径在同一临界区更新完整结构与有效标志；通知路径锁内生成一致快照、解锁后再调用外部回调；查询路径同锁读取。同时为成员补充默认初始化，消除首次保存前读取未初始化内存的问题。 ### 3. 修复 Bitmap 分配元数据并发竞争 - **问题**：Bitmap 的 allocedCnt_ 与 lastAllocIdx_ 为普通整数，并发 AllocId/FreeId 产生数据竞争及计数丢更新，高水位判断可能出错；较大分配范围留下的扫描起点可能越过后续较小分配的上限，造成超限分配（AllocId(64) 分配出 id ≥ 64）。 - **方案**：计数与扫描提示改为 Atomic；分配成功后原子加计数；释放通过 CAS 循环饱和减一（保留 OccupyId 不计数的既有语义）；扫描起点按当前位图上限取模归一化。 - **范围说明**：freeBitmap_ 指针首次发布与位元素访问的内存序同步属独立问题，本 PR 不扩展（见 commit message）。 ## 变更类型 - [x] 🐛 Bug 修复 ## 关联的Issue 无。如有对应 issue，请在右侧"关联Issue"部分补充链接并勾选"合并后关闭已关联的 Issue"。 ## 如何测试 1. 按仓内 UT 构建流程编译 runtime_utest 与 runtime_utest_api 目标； 2. 运行本 PR 新增的并发回归用例： - ApiExceptionTest.ConcurrentExceptionCallbackPairIsConsistent（双写者 + 读者校验 callback/userData 二元组一致性，混合配对即失败） - ProfileApiTest.ConcurrentProfSwitchSnapshotIsConsistent（并发切换开关时，通知回调收到的 rtProfCommandHandle_t 快照必须是完整一致的配置） - DriverTest.bitmap_concurrent_allocation_metadata（8 线程并发分配/释放 512 个 id，校验 id 唯一性与计数终值一致性） - DriverTest.bitmap_normalizes_allocation_hint_for_smaller_limit（128 容量分配 65 个 id 后以 64 上限申请应返回 -1，回归扫描起点归一化） 3. 回归运行相关既有套件：ApiExceptionTest.*、ProfileApiTest.*、DriverTest.*。 自测结果：上述新增用例全部通过，并发用例重复执行 20 次无抖动；相关套件全量回归通过与基线一致，无新增失败。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 - 变更均为内部实现（src/runtime/core 与内部头文件），不涉及 include/ 对外边界，无 API/ABI 兼容性影响，故无需文档同步。 See merge request: cann/runtime!5101 | 1 天前 |