You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Fix Issue #2856: Fix over allocated hashmap size in MULTI_CTA and MULTI_KERNEL Search Implementation - #3057
CAGRA’s MULTI_CTA and MULTI_KERNEL search plans passed hashmap_size in bytes to hashmap.resize(), which expects an element count. Both plans now pass hashmap_size / sizeof(INDEX_T). For uint32_t indices, this reduces the hashmap allocation to one quarter of its previous size.
Validation
Built with CUDA 12.9 and ran 17 existing CAGRA tests on an NVIDIA RTX PRO 6000 Blackwell Server Edition. All passed with zero failures or skips.
NEIGHBORS_ANN_CAGRA_BUGS_TEST — 8 passed, including hashmap sizing and fallback cases.
NEIGHBORS_ANN_CAGRA_FLOAT_UINT32_TEST — 5 passed.
NEIGHBORS_ANN_CAGRA_HALF_UINT32_TEST — 4 passed.
The float and half cases checked recall and distances for both search algorithms. The allocation reduction follows from the size conversion.
No actionable comments were generated in the recent review.
Summary
Summary by CodeRabbit
Bug Fixes
Corrected memory sizing during multi-CTA search setup. This helps ensure the search hashmap is allocated to the intended size and supports more reliable search behavior.
The multi-CTA and multi-kernel search paths now divide the byte-sized hashmap size by sizeof(INDEX_T) before passing it to hashmap.resize.
Changes: Hashmap allocation sizing
Layer / File(s)
Summary
Convert hashmap size before resize cpp/src/neighbors/detail/cagra/search_multi_cta.cuh, cpp/src/neighbors/detail/cagra/search_multi_kernel.cuh
Both search paths pass the hashmap size as an INDEX_T element count to hashmap.resize, instead of passing the byte count.
This change reduces the hashmap allocation in multi-CTA and multi-kernel CAGRA search to the intended size. No concrete merge-blocking risk was identified. The label checker failure only needs the missing labels added.
Architecture risk: Low · up to e2660
The change affects 1 system.
Changed systems:cpp
Architecture concerns
No architecture-level concerns identified.
Review details
Systems and components
observed — cpp (service) was modified; 2 changed files map to changed impact.
Before / after behavior
observed — Modified behavior in cpp/src/neighbors/detail/cagra/search_multi_cta.cuh: The initial hashmap allocation now passes hashmap_size / sizeof(INDEX_T) elements to resize instead of passing the byte count directly.
observed — Modified behavior in cpp/src/neighbors/detail/cagra/search_multi_kernel.cuh: search::set_params now passes hashmap_size / sizeof(INDEX_T) to hashmap.resize instead of passing hashmap_size directly.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title names the fix for issue #2856 and the affected search plans (MULTI_CTA and MULTI_KERNEL) and the over-allocated hashmap size. The changeset divides hashmap_size by sizeof(INDEX_T) in both se…
Description check
The description states the bug: MULTI_CTA and MULTI_KERNEL pass a byte count to hashmap.resize(), which expects an element count. It explains the fix (dividing by sizeof(INDEX_T)), the effect on uint3…
Linked Issues check
Issue #2856 requires the multi-CTA and multi-kernel search plans to use element-count units for hashmap sizing, matching the single-CTA plan. At head e2660ce, search_multi_cta.cuh (set_params) calls h…
Out of Scope Changes check
The whole-PR diff (merge base 918c8a3 to head e2660ce) changes only two files: search_multi_cta.cuh and search_multi_kernel.cuh. Each change is a single resize-argument conversion with a comment, and …
Full details: Title check
Explanation
The title names the fix for issue #2856 and the affected search plans (MULTI_CTA and MULTI_KERNEL) and the over-allocated hashmap size. The changeset divides hashmap_size by sizeof(INDEX_T) in both search plans, so the title matches the main change. It is somewhat long and includes the issue reference, but it is specific and accurate.
Full details: Description check
Explanation
The description states the bug: MULTI_CTA and MULTI_KERNEL pass a byte count to hashmap.resize(), which expects an element count. It explains the fix (dividing by sizeof(INDEX_T)), the effect on uint32_t allocation, and the tests run. This directly describes the changeset.
Full details: Linked Issues check
Explanation
Issue #2856 requires the multi-CTA and multi-kernel search plans to use element-count units for hashmap sizing, matching the single-CTA plan. At head e2660ce, search_multi_cta.cuh (set_params) calls hashmap.resize(hashmap_size / sizeof(INDEX_T), ...), and search_multi_kernel.cuh (set_params) makes the same change. Both now convert the byte count stored by calc_hashmap_params to an element count before resize(). The division is exact because hashmap_size is computed as sizeof(INDEX_T) * max_queries * hashmap::get_size(hash_bitlen). The single-CTA plan in search_single_cta.cuh already uses hashmap_element_count(), so the three plans now use consistent units. The PR adds no automated test. The author reports existing CAGRA tests passing, but the issue does not request a new test, so this does not count as a failure.
Full details: Out of Scope Changes check
Explanation
The whole-PR diff (merge base 918c8a3 to head e2660ce) changes only two files: search_multi_cta.cuh and search_multi_kernel.cuh. Each change is a single resize-argument conversion with a comment, and each directly implements the requirement in #2856. No unrelated changes, declaration changes, or refactoring appear in the diff.
Finishing Touches
Generate unit tests (beta)
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Included review availability: This review used your included allowance. Your plan provides up to 12 included reviews per hour; 11 remain after this review.
@achirkin Can you take a look and approve if it looks good?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2856
Summary
CAGRA’s
MULTI_CTAandMULTI_KERNELsearch plans passedhashmap_sizein bytes tohashmap.resize(), which expects an element count. Both plans now passhashmap_size / sizeof(INDEX_T). Foruint32_tindices, this reduces the hashmap allocation to one quarter of its previous size.Validation
Built with CUDA 12.9 and ran 17 existing CAGRA tests on an NVIDIA RTX PRO 6000 Blackwell Server Edition. All passed with zero failures or skips.
NEIGHBORS_ANN_CAGRA_BUGS_TEST— 8 passed, including hashmap sizing and fallback cases.NEIGHBORS_ANN_CAGRA_FLOAT_UINT32_TEST— 5 passed.NEIGHBORS_ANN_CAGRA_HALF_UINT32_TEST— 4 passed.The float and half cases checked recall and distances for both search algorithms. The allocation reduction follows from the size conversion.