| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
【bugfix】修复uninstall.sh卸载时cd失败及pip3崩溃问题 Co-authored-by: SoulMeister<zhangshuren@h-partners.com> # message auto-generated for no-merge-commit merge: !430 merge bugfix/uninstall_cd_failure into develop 【bugfix】修复uninstall.sh卸载时cd失败及pip3崩溃问题 Created-by: SoulMeister Commit-by: SoulMeister Merged-by: yrewzjsx Description: # 合入来源 - [ ] 需求 - [x] 问题单 - [ ] issue # 问题/功能描述 当前使用run包安装后，再执行卸载脚本，会报错路径异常以及pip包无法卸载成功的问题，本pr修改了uninstall.sh以修复这两个问题 # 修改方案描述 1、在删除安装目录前保存安装目录路径，保证后续读取正常 2、在执行pip命令卸载前切换到有效目录，避免pip get_cwd报错 # 是否涉及UT/ST - [ ] 是 - [x] 否（说明理由：非业务代码修改） # 开发自检 - [x] 规范：未超过1k；超过1k已完成备案；反合入需要标题注明【反合】 - [x] 规范：已关联issue或里程碑 - [x] 规范：不需要UT/ST且已说明理由；需要且已包含UT/ST - [x] 安全：涉及对外接口/参数/环境变量改动，并同步修改资料 - [x] 安全：未引入三方开源软件；引入三方开源软件并经过安全评审 - [x] 安全：未新增对外接口/参数；新增对外接口/参数有校验 - [x] 规范：未涉及资料改动；涉及资料改动并已完成修改 See merge request: Ascend/memcache!430 | 1 个月前 | |
[feature] 新增日志收集脚本 Co-authored-by: mrh1024<marunhua1@h-partners.com> # message auto-generated for no-merge-commit merge: !489 merge develop_fix_memcache into develop [feature] 新增日志收集脚本 Created-by: mrh1024 Commit-by: mrh1024 Merged-by: yrewzjsx Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue # 问题/功能描述 1.环境配套信息：内核版本、OS版本、HDK版本、CANN版本、memcache版本、memfabric版本、vllm_ascend版本 2.日志打印：打点日志：/var/log/memfabirc_hybrid/、meta日志：/var/log/memcache_hybrid/logs、plog日志：/root/ascend/log/debug/plog、dmesg日志 # 修改方案描述  # 是否涉及UT/ST - [ ] 是 - [x] 否（说明理由） # 开发自检 - [ ] 规范：未超过1k；超过1k已完成备案；反合入需要标题注明【反合】 - [ ] 规范：已关联issue或里程碑 - [ ] 规范：不需要UT/ST且已说明理由；需要且已包含UT/ST - [ ] 安全：涉及对外接口/参数/环境变量改动，并同步修改资料 - [ ] 安全：未引入三方开源软件；引入三方开源软件并经过安全评审 - [ ] 安全：未新增对外接口/参数；新增对外接口/参数有校验 - [ ] 规范：未涉及资料改动；涉及资料改动并已完成修改 See merge request: Ascend/memcache!489 | 1 个月前 | |
[反合][docs]根据doc tools扫描结果优化资料 Co-authored-by: whytao<weitao46@h-partners.com> # message auto-generated for no-merge-commit merge: !418 merge develop into develop [反合][docs]根据doc tools扫描结果优化资料 Created-by: whytao Commit-by: whytao Merged-by: yrewzjsx Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue fixes [#190](https://gitcode.com/Ascend/memcache/issues/190) # 问题/功能描述 # 修改方案描述 # 是否涉及UT/ST - [ ] 是 - [x ] 否（说明理由） # 开发自检 - [ ] 规范：未超过1k；超过1k已完成备案；反合入需要标题注明【反合】 - [ ] 规范：已关联issue或里程碑 - [ ] 规范：不需要UT/ST且已说明理由；需要且已包含UT/ST - [ ] 安全：涉及对外接口/参数/环境变量改动，并同步修改资料 - [ ] 安全：未引入三方开源软件；引入三方开源软件并经过安全评审 - [ ] 安全：未新增对外接口/参数；新增对外接口/参数有校验 - [ ] 规范：未涉及资料改动；涉及资料改动并已完成修改 See merge request: Ascend/memcache!418 | 1 个月前 | |
feat: LRU 分片降低高并发锁竞争 Co-authored-by: lirui7717<lirui7717@163.com> # message auto-generated for no-merge-commit merge: !607 merge feat/sharded-lru-global-eviction-methodology into master feat: LRU 分片降低高并发锁竞争 Created-by: lirui7717 Commit-by: lirui7717 Merged-by: yangchangjie12138 Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue 本pr 来源自https://gitcode.com/Ascend/memcache/pull/401 # 问题/功能描述 - 当前所有 Put、Get 等请求共享同一条 LRU 链及其锁。高并发场景下，不同 key 的操作也会互相等待，LRU 锁竞争成为性能瓶颈。 - 由于分shard 导致benchmark 太快，发现backup还没完成client就注销了， backup 线程和注销线程形成死锁。 # 修改方案描述 将单条全局 LRU 链拆分为 16 个 shard。 每个 shard 维护独立的 LRU 链和锁，key 按 hash 分配到对应 shard。不同 shard 的请求可以并发执行，减少锁竞争；同一 key 始终落在固定 shard，原有 LRU 语义保持不变。 其中改动最大的是MultiLevelElimination 也就是基于shard 全局淘汰。其思想是这样的： 1. 先轻量级收集每个shard的最后一个节点的每个访问序号，用最小堆选出全局淘汰的边界。 2. 确定全局淘汰边界后，再把边界以内的真实 key 候选收集出来。 3. 正常候选不够目标数，说明两个阶段之间发生了较严重的并发变化， 重新收集candidate，重新计算边界 4. 最后在锁的保护下实现真正的驱逐 默认为shard_lru ock.mmc.meta_service.lru_shard_count = 16 死锁解决方案为：直接不让注销线程和backup线程并行，已经启动backup的就继续backup，还没backup的就取消，之后注销线程等backup结束后再注销。 执行 bash script/build_and_pack_run.sh --build_mode RELEASE --build_cpp_example ON RUN_ARGS='-p 4 -t 4 -n 20000 -k 20000 -w 4000 -s 65536 -c 64 -r 30 -b 16,32' ./build/example/meta_service_bench/bench_meta_service $RUN_ARGS | 指标 | 非 Shard | Shard | Shard + 淘汰优化| | ------- | ---------: | ---------: |-------------: | | Get Avg | 300 us | 145 us | **171 us** | | Get P95 | 1024 us | 256 us | **512 us** | | Get P99 | 1024 us | 512 us | **512 us** | | Put Avg | 11.3 ms | 16.2 ms | **8.57 ms** | | 吞吐 | 4400 ops/s | 3187 ops/s | **5911 ops/s** | # 是否涉及UT/ST - [x] 是 新增/更新 UT，覆盖： - key 能稳定分配到对应 shard； - 各 shard 的插入、查询、淘汰行为正确； - 并发访问不同 shard 时功能正常。 - [ ] 否（说明理由） # 开发自检 - [ ] 规范：未超过1k；超过1k已完成备案；反合入需要标题注明【反合】 - [ ] 规范：已关联issue或里程碑 - [x] 规范：不需要UT/ST且已说明理由；需要且已包含UT/ST - [x] 安全：涉及对外接口/参数/环境变量改动，并同步修改资料 - [x] 安全：未引入三方开源软件；引入三方开源软件并经过安全评审 - [x] 安全：未新增对外接口/参数；新增对外接口/参数有校验 - [x] 规范：未涉及资料改动；涉及资料改动并已完成修改 See merge request: Ascend/memcache!607 | 3 天前 | |
feat: LRU 分片降低高并发锁竞争 Co-authored-by: lirui7717<lirui7717@163.com> # message auto-generated for no-merge-commit merge: !607 merge feat/sharded-lru-global-eviction-methodology into master feat: LRU 分片降低高并发锁竞争 Created-by: lirui7717 Commit-by: lirui7717 Merged-by: yangchangjie12138 Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue 本pr 来源自https://gitcode.com/Ascend/memcache/pull/401 # 问题/功能描述 - 当前所有 Put、Get 等请求共享同一条 LRU 链及其锁。高并发场景下，不同 key 的操作也会互相等待，LRU 锁竞争成为性能瓶颈。 - 由于分shard 导致benchmark 太快，发现backup还没完成client就注销了， backup 线程和注销线程形成死锁。 # 修改方案描述 将单条全局 LRU 链拆分为 16 个 shard。 每个 shard 维护独立的 LRU 链和锁，key 按 hash 分配到对应 shard。不同 shard 的请求可以并发执行，减少锁竞争；同一 key 始终落在固定 shard，原有 LRU 语义保持不变。 其中改动最大的是MultiLevelElimination 也就是基于shard 全局淘汰。其思想是这样的： 1. 先轻量级收集每个shard的最后一个节点的每个访问序号，用最小堆选出全局淘汰的边界。 2. 确定全局淘汰边界后，再把边界以内的真实 key 候选收集出来。 3. 正常候选不够目标数，说明两个阶段之间发生了较严重的并发变化， 重新收集candidate，重新计算边界 4. 最后在锁的保护下实现真正的驱逐 默认为shard_lru ock.mmc.meta_service.lru_shard_count = 16 死锁解决方案为：直接不让注销线程和backup线程并行，已经启动backup的就继续backup，还没backup的就取消，之后注销线程等backup结束后再注销。 执行 bash script/build_and_pack_run.sh --build_mode RELEASE --build_cpp_example ON RUN_ARGS='-p 4 -t 4 -n 20000 -k 20000 -w 4000 -s 65536 -c 64 -r 30 -b 16,32' ./build/example/meta_service_bench/bench_meta_service $RUN_ARGS | 指标 | 非 Shard | Shard | Shard + 淘汰优化| | ------- | ---------: | ---------: |-------------: | | Get Avg | 300 us | 145 us | **171 us** | | Get P95 | 1024 us | 256 us | **512 us** | | Get P99 | 1024 us | 512 us | **512 us** | | Put Avg | 11.3 ms | 16.2 ms | **8.57 ms** | | 吞吐 | 4400 ops/s | 3187 ops/s | **5911 ops/s** | # 是否涉及UT/ST - [x] 是 新增/更新 UT，覆盖： - key 能稳定分配到对应 shard； - 各 shard 的插入、查询、淘汰行为正确； - 并发访问不同 shard 时功能正常。 - [ ] 否（说明理由） # 开发自检 - [ ] 规范：未超过1k；超过1k已完成备案；反合入需要标题注明【反合】 - [ ] 规范：已关联issue或里程碑 - [x] 规范：不需要UT/ST且已说明理由；需要且已包含UT/ST - [x] 安全：涉及对外接口/参数/环境变量改动，并同步修改资料 - [x] 安全：未引入三方开源软件；引入三方开源软件并经过安全评审 - [x] 安全：未新增对外接口/参数；新增对外接口/参数有校验 - [x] 规范：未涉及资料改动；涉及资料改动并已完成修改 See merge request: Ascend/memcache!607 | 3 天前 | |
feature：支持异步即时刷盘 Co-authored-by: gcw_qYJeyWK4<jiangbo97@huawei.com> # message auto-generated for no-merge-commit merge: !380 merge doc/async-flush-rebase-v2 into develop feature：支持异步即时刷盘 Created-by: gcw_qYJeyWK4 Commit-by: gcw_qYJeyWK4;Super User Merged-by: yrewzjsx Description: # 合入来源 - [x] 需求 - [ ] 问题单 - [ ] issue # 问题/功能描述 # 修改方案描述 新增 3 个配置项：ock.mmc.storage.async_flush.enabled（默认 false）、interval_ms（默认 1000ms）、batch_limit（默认 1024），meta 和 local 两侧均可配。 MetaReplicateRequest 新增 asyncFlush_ 字段：标记本次 backup 请求是否为异步刷盘，local 侧据此决定是否执行 SSD 写入。 Response 新增 asyncFlushBlobs_ 字段：local 侧将刷盘成功的 SSD blob 列表带回给 meta 侧。 数据流（PUT 路径） backup 线程周期性唤醒：条件变量从 wait 改为 wait_for，按配置的 interval_ms 定时扫描待刷盘队列，不再仅依赖事件驱动。 批量可配：原硬编码 BATCH_BACKUP_SIZE=1024 改为可配置的 flushBatchLimit_。 通知策略分层：Add/Remove 在 async 模式下改为攒批通知 —— 队列达到 flushBatchLimit_ 时才 notify，避免频繁唤醒。 local 侧三阶段处理：UpdateMetaBackup 拆为锁内元数据操作 → 锁外 BatchFlushToSsd 批量 SSD I/O → 异步回写 SSD desc 到 blobMap_。 I/O 线程池卸载：HandleMetaReplicate 支持将处理提交到 ubsioEventPool_，避免阻塞网络线程。 刷盘结果回传：backup 线程收到 Response 后回调 OnAsyncFlushComplete → AddSsdBlob，将 SSD 副本注册到 meta manager 的 objMeta 中。 数据流（淘汰路径） 跳过 CopyBlob：MoveBlob 在 async flush 已启用且目标介质为 SSD 时，跳过耗时的 DRAM→SSD 拷贝，直接 PushRemoveList 回收 DRAM（数据已由异步刷盘提前落地）。 # 是否涉及UT/ST - [ ] 是 - [x] 否（说明理由） # 开发自检 - [x] 规范：未超过1k；超过1k已完成备案；反合入需要标题注明【反合】 - [x] 规范：已关联issue或里程碑 - [x] 规范：不需要UT/ST且已说明理由；需要且已包含UT/ST - [x] 安全：涉及对外接口/参数/环境变量改动，并同步修改资料 - [x] 安全：未引入三方开源软件；引入三方开源软件并经过安全评审 - [x] 安全：未新增对外接口/参数；新增对外接口/参数有校验 - [x] 规范：未涉及资料改动；涉及资料改动并已完成修改 See merge request: Ascend/memcache!380 | 1 个月前 | |
【ci】修复devcontainer校验脚本的容器残留、SIGPIPE中止与NPU选卡问题 Co-authored-by: littleyellowbicycle<liguo29@h-partners.com> # message auto-generated for no-merge-commit merge: !482 merge fix_ci into develop 【ci】修复devcontainer校验脚本的容器残留、SIGPIPE中止与NPU选卡问题 Created-by: littleyellowbicycle Commit-by: littleyellowbicycle Merged-by: yrewzjsx Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [ √] issue # 问题/功能描述 1. 特殊情况会残留容器 2. 执行用例前没有校验使用的卡是否空闲 # 修改方案描述 1. 退出时增强清理残留容器的流程 2. 在 NPU 探测之后， 选一张空闲卡并让子进程继承。各段原有的 NPU_IDLE -lt 1 整段 skip 逻辑保留——0 张空闲仍整段跳过，这只在 ≥1 张空闲时选卡 # 是否涉及UT/ST - [ √] 是 - [ ] 否（说明理由） # 开发自检 - [ √] 规范：未超过1k；超过1k已完成备案；反合入需要标题注明【反合】 - [ √] 规范：已关联issue或里程碑 - [ √] 规范：不需要UT/ST且已说明理由；需要且已包含UT/ST - [ √] 安全：涉及对外接口/参数/环境变量改动，并同步修改资料 - [ √] 安全：未引入三方开源软件；引入三方开源软件并经过安全评审 - [ √] 安全：未新增对外接口/参数；新增对外接口/参数有校验 - [ √] 规范：未涉及资料改动；涉及资料改动并已完成修改 See merge request: Ascend/memcache!482 | 1 个月前 | |
[ci] style: 引入 pre-commit 并应用全代码库格式化 Co-authored-by: shilinlee<836160610@qq.com> # message auto-generated for no-merge-commit merge: !347 merge worktree-precommit-format into develop [ci] style: 引入 pre-commit 并应用全代码库格式化 Created-by: shilinlee_com Commit-by: shilinlee Merged-by: yrewzjsx Description: ## 合入来源 - [ ] 需求 - [x] 问题单 - [ ] issue ## 问题/功能描述 引入 pre-commit CI 格式化检查机制，并对全代码库应用自动格式化修正。 ## 修改方案描述 1. 新增/更新 pre-commit 基础设施： .clang-format、.pre-commit-config.yaml、script/ci-pre-commit-pr.sh CI 脚本 2. 对全代码库执行 pre-commit 自动格式化：clang-format、文件末尾补换行、去除尾随空格等 ## 是否涉及UT/ST - [ ] 是 - [x] 否（说明理由：纯格式化调整，不涉及功能逻辑改动） ## 开发自检 - [x] 规范：未超过1k；超过1k已完成备案；反合入需要标题注明【反合】 - [x] 规范：已关联issue或里程碑 - [x] 规范：不需要UT/ST且已说明理由；需要且已包含UT/ST - [x] 安全：涉及对外接口/参数/环境变量改动，并同步修改资料 - [x] 安全：未引入三方开源软件；引入三方开源软件并经过安全评审 - [x] 安全：未新增对外接口/参数；新增对外接口/参数有校验 - [x] 规范：未涉及资料改动；涉及资料改动并已完成修改 See merge request: Ascend/memcache!347 | 2 个月前 | |
refactor: memcache通过运行时C ABI解耦memfabric Co-authored-by: zhangjialee<z3262749952@163.com> # message auto-generated for no-merge-commit merge: !536 merge fix/memfabric-decouple into develop refactor: memcache通过运行时C ABI解耦memfabric Created-by: zhangjialee Commit-by: zhangjialee Merged-by: chenyz6 Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue 关联 issue：[Ascend/memcache #281](https://gitcode.com/Ascend/memcache/issues/281) # 问题/功能描述 Issue #281：MemCache 将 MemFabric 作为三方库参与编译并直接使用其 C++ 类型。编译期 MF 与运行时 libmf_smem.so 的小版本或 C++ ABI 不一致时，同名 C++/STL 符号可能发生进程级抢占，MetaService 在 AccCommonServerOptions::operator=、std::string::assign 等位置 coredump。普通 dlopen 仍不足以隔离两套 C++ ABI。 # 修改方案描述 修改点： - 删除 MemCache 对 3rdparty/memfabric_hybrid 的编译、链接、头文件及 Python 包依赖，运行时固定加载 libmf_smem.so，不新增环境变量。 - ACC、ConfigStore、BM 分模块定义 def/API 封装，通过 dlopen/dlsym 调用 MF 纯 C ABI，并保持原有 C++ 驼峰调用接口。 - ConfigStore 适配类使用 ock::mmc_smem 实际命名空间，通过 ock::smem 别名保持调用侧不变，避免与 MF 原生 ock::smem C++ 符号冲突。 - dlopen 使用 RTLD_NOW | RTLD_LOCAL | RTLD_DEEPBIND，隔离 ABI0/ABI1 的 libstdc++ 弱模板符号。 - 兼容性匹配规则： - 版本来源：MMC 和 MF 均使用各自根目录的 VERSION。 - 版本编码：高 16 位为 major，低 16 位为 minor。 - 匹配条件：MMC 与运行时 MF 的 major.minor 必须完全一致，patch 不参与匹配。 - 当前分支：develop 为 1.3.x，仅匹配 MF 1.3.x；1.1.x、1.2.x 等其他版本线均拒绝加载。 - 必需接口：MF 必须导出 smem_get_abi_version，以及 MMC 实际使用的 ACC、ConfigStore、BM 模块全部必需 C ABI 符号。 - 失败行为：任一必需符号缺失或版本不匹配，均记录期望/实际版本或缺失符号并快速退出，避免 coredump。 - 结构长度：当前没有独立的结构长度字段校验，C ABI 结构布局兼容性由相同 major.minor 约束。 - Python 绑定的复制方向默认值显式转换为 int32_t，避免未注册枚举导致模块导入失败。 # 测试结果： 验证结果： - 构建与单元测试：develop DEBUG 构建成功，release/1.2 完整构建 221/221 成功；test_mf_smem_api 2/2 PASSED。 - C++ ABI 组合启动：同一 MMC 产物分别加载采用 libstdc++ ABI0、ABI1 构建的兼容版本 MF，MetaService 均启动成功，/health 返回 HTTP 200。 - 异常依赖启动：缺少 libmf_smem.so、缺少 smem_get_abi_version、缺少模块必需符号或 major.minor 不匹配时，均输出明确错误并快速退出，无 core。 - ELF 解耦检查：libmf_memcache.so 不包含对 libmf_smem.so、libacc_tcp_net.so 的 DT_NEEDED，也不存在未解析 ock::smem C++ 符号。 - CPU/host_shm benchmark：MF ABI0、ABI1 组合均完成写读，读取返回 0，逐轮写读校验和一致。 - NPU 基础初始化：acl.init 及两张 NPU 卡的 acl.rt.set_device 均返回 0，MetaService 健康检查通过。 - 双卡 device_sdma benchmark：每卡写读 256 MiB；卡 1 写/读 1.616/1.463 GB/s，写读校验和均为 1070032372；卡 2 写/读 1.571/1.481 GB/s，写读校验和均为 1069712602；读取返回 0，无 core。 - 四卡端到端推理验证： - 软件组合：vLLM 0.23.0、Qwen3-32B-W8A8、TP=4；模型列表接口返回 HTTP 200，聊天冒烟请求成功生成 64 tokens，各 TP worker 加载约 9.994 GiB 权重。 - 并发 1：8/8 请求成功、0 失败；耗时 19.58 s，请求吞吐 0.41 req/s，输出吞吐 52.31 tok/s，总吞吐 470.77 tok/s；平均 TTFT 155.15 ms，P99 TTFT 172.99 ms，平均 TPOT 18.04 ms，P99 TPOT 18.08 ms。 - 并发 16：32/32 请求成功、0 失败；耗时 6.07 s，请求吞吐 5.27 req/s，输出吞吐 674.48 tok/s，峰值输出吞吐 768 tok/s，总吞吐 6070.29 tok/s；平均 TTFT 335.07 ms，P99 TTFT 364.77 ms，平均 TPOT 21.24 ms，P99 TPOT 22.30 ms。 # 是否涉及UT/ST - [x] 是：已执行，结果见“测试结果”章节 - [ ] 否（说明理由）： # 开发自检 - [x] 规范：未超过1k；超过1k已完成备案；反合入需要标题注明【反合】 - [x] 规范：已关联issue或里程碑 - [x] 规范：不需要UT/ST且已说明理由；需要且已包含UT/ST - [x] 安全：涉及对外接口/参数/环境变量改动，并同步修改资料 - [x] 安全：未引入三方开源软件；引入三方开源软件并经过安全评审 - [x] 安全：未新增对外接口/参数；新增对外接口/参数有校验 - [x] 规范：未涉及资料改动；涉及资料改动并已完成修改 See merge request: Ascend/memcache!536 | 15 天前 | |
fix_dos2unix_with_sed_fallback Co-authored-by: Hututu-w<wangyibing13@huawei.com> # message auto-generated for no-merge-commit merge: !448 merge fix_dos2unix_with_sed_fallback into develop fix_dos2unix_with_sed_fallback Created-by: Hututu-w Commit-by: Hututu-w Merged-by: yrewzjsx Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue # 问题/功能描述 script/\*.sh 在执行前无条件调用外部命令 dos2unix ，缺少该工具时会在开始构建前直接退出 # 修改方案描述 无dos2unix时，用Linux 自带 GNU sed替代 # 是否涉及UT/ST - [ ] 是 - [x] 否（说明理由） # 开发自检 - [x] 规范：未超过1k；超过1k已完成备案；反合入需要标题注明【反合】 - [x] 规范：已关联issue或里程碑 - [x] 规范：不需要UT/ST且已说明理由；需要且已包含UT/ST - [x] 安全：涉及对外接口/参数/环境变量改动，并同步修改资料 - [x] 安全：未引入三方开源软件；引入三方开源软件并经过安全评审 - [x] 安全：未新增对外接口/参数；新增对外接口/参数有校验 - [x] 规范：未涉及资料改动；涉及资料改动并已完成修改 See merge request: Ascend/memcache!448 | 1 个月前 | |
[core] feat: 默认启用 56-bit GVA，移除 32T 容量阈值限制 Co-authored-by: shilinlee<836160610@qq.com> # message auto-generated for no-merge-commit merge: !355 merge mmc_enable_56bit_always into develop [core] feat: 默认启用 56-bit GVA，移除 32T 容量阈值限制 Created-by: shilinlee_com Commit-by: shilinlee Merged-by: chenyz6 Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue # 问题/功能描述 当前 56-bit GVA 仅在池化总容量（localMaxDRAMSize + localMaxHBMSize）* worldSize > 32TB 时自动启用。此阈值限制导致部分场景（如 device_urma/device_uboe 协议但配置容量未超过 32TB）无法获得 56-bit GVA 的大地址空间优势，且池化总大小大于 32TB 的要求对用户构成文档约束和配置困扰。现决定无条件默认启用 56-bit GVA，移除该阈值判断逻辑及相关文档限制。 # 修改方案描述 1. 无条件启用 56-bit GVA 2. 移除 32T 文档限制 # 是否涉及UT/ST   - [x] 是 - [ ] 否（说明理由） # 开发自检 - [x] 规范：未超过 1k；超过 1k 已完成备案；反合入需要标题注明【反合】 - [ ] 规范：已关联 issue 或里程碑 - [x] 规范：不需要 UT/ST 且已说明理由；需要且已包含 UT/ST - [x] 安全：涉及对外接口/参数/环境变量改动，并同步修改资料 - [x] 安全：未引入三方开源软件；引入三方开源软件并经过安全评审 - [x] 安全：未新增对外接口/参数；新增对外接口/参数有校验 - [x] 规范：未涉及资料改动；涉及资料改动并已完成修改 See merge request: Ascend/memcache!355 | 1 个月前 |
script
1 install dir
${INSTALL_PATH}/
|--memcache_hybrid
|-- latest
|-- set_env.sh
|-- ${version}
|-- ${arch}-${os}
|-- include (头文件)
|-- bin (用于TLS相关二进制文件)
|-- lib64 (so库)
|-- whl (python的whl包)
|-- uninstall.sh
|-- version.info
default ${INSTALL_PATH} is /usr/local/
2 rule of package name
memcache_hybrid-${version}_${os}_${arch}.run
3 upgrade
support offline upgrade
4 where is the package
built from gitee and placed on gitee for downloading
5 check library version
user can get library version by linux 'strings' command
example to get the library version using 'strings' as following:
strings libmf_smem.so | grep commit
library version: 1.0.0, build time: Apr 27 2025 08:46:17, commit: 4ad27e5b4bd3353c5c20f16e8f3b6da41268d4e0