Repository navigation
[BUG] CAGRA multi-CTA and multi-kernel search over-allocate the hashmap they use #2856
Description
Describe the bug
search_plan_impl::calc_hashmap_params stores the size of the global hashmap in bytes (search_plan.cuh#L375):
hashmap_size = sizeof(INDEX_T) * max_queries * hashmap::get_size(hash_bitlen);hashmap is a lightweight_uvector<INDEX_T> (#L157), whose resize takes an element count and allocates new_size * sizeof(T) bytes from the workspace resource (#L62-L68). The single-CTA plan converts the size to an element count before resizing (search_single_cta.cuh#L209-L210). The multi-CTA and multi-kernel plans pass the byte count as if it were element count:
So both allocate 4x the table for uint32_t indices.
3/4 of each allocation is never touched.
Expected behavior
All functions should use the right units
Activity
[-][BUG] CAGRA multi-CTA and multi-kernel search over-allocate the hashmap and top-k workspace they use[/-][+][BUG] CAGRA multi-CTA and multi-kernel search over-allocate the hashmap they use[/+]mc8max commentedon Nov 13, 2026
@irina-resh-nvda I am checking this issue.
Do you think it is better to convert the hashmap_size to be element counts, in all three search plan files or apply conversion in the Multi CTA and Multi Kernel search plan?
irina-resh-nvda commentedon Nov 13, 2026
Either approach will do, your PR looks fine