[memory]: Memory breakdown reporting and estimation functionality have to handle Hugepage allocations rounded to 2MB

未关闭
  • 哪里不对？
#386 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 5 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
cpp
领域
backend, performance

调研方向

先阅读 IndexBuilder 和 svs_index_builder_estimate_memory 入口点，然后检查 dispatcher_vamana.cpp 第 159 行附近的 dispatch_vamana_memory_estimate 及其对 SimpleDataBuilder 的使用。将估算器与已配置分配器的行为进行比较。完成标准是 hugepage 分配包含按 2 MiB 向上取整，并且自定义分配器的估算不再忽略分配器，同时不降低运行时行为。

由索引模型根据 Issue 内容生成。

描述

This is the fallout from IndexBuilder storing a live handle rather than a builder: the estimator has no way to know which allocator was configured, so it has to hardcode one. The result is that svs_index_builder_estimate_memory_dynamic is wrong for SVS_ALLOCATOR_KIND_HUGE_PAGE (2 MiB rounding is unaccounted for) and wrong for any custom allocator. dispatch_vamana_memory_estimate (~line 159 of dispatcher_vamana.cpp, unchanged here) is allocator-blind entirely — it still uses SimpleDataBuilder<index_type>{}.

Note that if the motivation for defaulting to lib::Allocator was to make the estimate line up with within_1pct(tracker.live_bytes, memory_usage) in the new tests, that's fixing the estimator's inaccuracy by degrading the runtime. Threading the kind through instead fixes both.

Originally posted by @ethanglaser in #380

主要语言
C++
星标
241
派生
48
平均合并
4 天 21 小时
30 天内合并 PR
11

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

intel/ScalableVectorSearch 的其他 Issue

查看 intel/ScalableVectorSearch 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。