-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Improve C++ test coverage #906
Comments
This issue has been labeled |
Currently only arena_mr and arena.hpp need coverage improved. As of #920 coverage of most files is 100%. |
We also need to look at getting coverage testing into CI. |
This issue has been labeled |
With the latest code it shows |
At 100% now. |
Currently the arena allocator divides GPU memory into a global arena and per-thread arenas. For smaller allocations, a per-thread arena allocates large chunks of memory (superblocks) from the global arena and divides them up for individual allocations. However, when deallocating from another arena (producer/consumer pattern), or when we run out of memory and return everything to the global arena, the superblock boundaries are broken. Overtime, this could cause the memory to get more and more fragmented. This PR makes superblocks concrete objects, not just virtual boundaries, and the only units of exchange between the global arena and per-thread arenas. This should make the allocator more resistant to memory fragmentation, especially for long running processes under constant memory pressure. Other notable changes: * The allocator now allocates a fixed but configurable amount of memory from CUDA. This introduces less fragmentation comparing to growing the pool size gradually. * Switched to C++17 `std::shared_mutex`. * Added a bunch of unit tests. fixes #919 fixes #906 Authors: - Rong Ou (https://github.com/rongou) Approvers: - Jake Hemstad (https://github.com/jrhemstad) - Mark Harris (https://github.com/harrism) URL: #916
With #905 we now have C++ code coverage analysis for RMM. Coverage is not bad in a lot of places, but can be improved (we're at about 77%).
It shouldn't be hard to close the gaps, they are mostly tests of simple infrequently used methods on memory resources and containers.
The text was updated successfully, but these errors were encountered: