-
Notifications
You must be signed in to change notification settings - Fork 35
Initial memspace and memory_target APIs #53
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
Conversation
What you described makes sense but to break it down into several independent steps I suggest the following:
Perhaps, steps 2 & 3 are dependant. Let's expose only required APIs for each step but design the implementation with all future use cases in mind. |
402c168
to
c61e914
Compare
1b501c9
to
b818231
Compare
Implementation for NUMA is here: igchor#1 |
d78c8fc
to
ad09620
Compare
ad09620
to
0740413
Compare
b81f25d
to
978584d
Compare
4b99aea
to
801276c
Compare
@vinser52 I think we could go with this code - I know it still needs some changes in the future, but I think it is a good basis for introducing the memspace API |
include/umf/memspace.h
Outdated
/// \brief Destroys memspace | ||
/// \param hMemspace handle to memspace | ||
/// | ||
void umfMemspaceDestroy(umf_memspace_handle_t hMemspace); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is the corresponding create function?
Another question: if we consider only predefined memspaces as a first step do we need Create/Destroy functions for memspaces in a public API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now we only have umfMemspaceCreateFromNumaArray
that is defined in memspace_numa.h
We could move that function to memspace.h for now but in the long term, I think those create functions should be in separate headers (since we might want to have the memspaces in separate libs).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another question: if we consider only predefined memspaces as a first step do we need Create/Destroy functions for memspaces in a public API?
Ok, good point. @bratpiorka for openMP, we won't need umfMemspaceCreateFromNumaArray
right? If that's the case I can make it internal for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. I've made those functions private for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR does not expose the predefined memspaces but this will be added in next PR (it requires integrating with hwloc).
@vinser52 please take a look. We'd like to unblock next step which is implementing HOST_MEMSPACE |
umf_memspace_policy_handle_t policy, umf_memory_pool_handle_t *pool); | ||
|
||
umf_result_t (*memory_provider_create_from_memspace)( | ||
umf_memspace_handle_t memspace, void **memoryTargets, size_t numTargets, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what if memspace
consists of multiple memory_targets
? How we will choose which memory_target
should we ask to create a pool or provider from memspace
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's why we only support memory targets of the same type for now. See here:
unified-memory-framework/src/memspace.c
Line 68 in 9c4e3da
assert(verifyMemTargetsTypes(memspace) == UMF_RESULT_SUCCESS); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that today we support only memory targets of the same type (same ops structure). My question is mostly about the architecture/design, not the current implementation. if we are creating pool/provider from memspace perhaps the current design is wrong and memspace should be responsible for pool/provider creation? In the future I can imagine memspace which consists of GPU memory target and numa memory target - in that case I expect that we will choose GPU memory provider (L0 or cuda) and create USM shared pool.
What do you think?
This is an initial draft of APIs for memspace and memory_target (without any actual implementation).
A few things to discuss: