-
Notifications
You must be signed in to change notification settings - Fork 898
opal: add basic memory accounting for free lists and objects #6282
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
base: main
Are you sure you want to change the base?
Conversation
This commit adds support for exposing free list and object memory allocation through the MPI_T pvar interface. Memory tracking of free list memory is enabled by default for all builds. OPAL object memory tracking is only enabled for debug builds. In addition this commit updates the pvar interface to pass the pvar handle to the read function instead of the pvar. This gives the read function access to the count returned when the handle was bound. Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
I saw this yesterday and had mitigated feeling about. I understand the need for tracking allocations, I am not sure about the need to know where it is used, especially not at the granularity you are providing here. However, the overhead was one of my original concerns, but as I went through the code my fears about a significant overhead vanished, the code looks neat and clean. Why not having a memory allocator MCA, so that application can register tracking hooks (and identify their location based on the stack trace) ? This is not new but has the advantage of requiring minimal code in the OMPI tree. |
@bosilca That isn't a bad idea. We can re-purpose the mpool framework to allow the base allocators to be used before the framework is opened. Then we can make all internal allocations use the default allocator and do all the accounting on mpools (which would also get free list allocations). I don't think it would take too much work. |
One question is how much info we want to track. OpenUCX tracks each individual allocation but we probably only really care about total size (for most cases). |
Can one of the admins verify this patch? |
@hjelmn Looks like this PR got forgotten about. Do you still want to work on it? |
Maybe. Let me figure out where I was on it. |
@hjelmn ? |
Will look tomorrow. Finding time where I can. |
This commit adds support for exposing free list and object memory
allocation through the MPI_T pvar interface. Memory tracking of free
list memory is enabled by default for all builds. OPAL object memory
tracking is only enabled for debug builds.
In addition this commit updates the pvar interface to pass the pvar
handle to the read function instead of the pvar. This gives the read
function access to the count returned when the handle was bound.
Signed-off-by: Nathan Hjelm hjelmn@lanl.gov