-
Notifications
You must be signed in to change notification settings - Fork 117
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
[uma] Replace list of providers with explicit data and metadata providers. #641
Closed
Closed
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -49,7 +49,7 @@ struct uma_memory_provider_ops_t { | |
size_t *pageSize); | ||
enum uma_result_t (*purge_lazy)(void *provider, void *ptr, size_t size); | ||
enum uma_result_t (*purge_force)(void *provider, void *ptr, size_t size); | ||
void (*get_name)(void *provider, const char **ppName); | ||
const char *(*get_name)(void *provider); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: looks like a change unrelated to this PR. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes, that's why I've put it into a separate commit, it's just a small improvement |
||
}; | ||
|
||
#ifdef __cplusplus | ||
|
This file contains 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
This file contains 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
Oops, something went wrong.
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.
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.
it is a non-flexible API. As I remember in the past you had an idea of passing a list of memory providers with the lists of types. Have you considered it as an alternative.
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.
Yes, as I mentioned in the PR description we might want to accept a list of provides with types. However, for that we would need to define some properties for memory providers (so that the pool can choose the appropriate one) and we don't have those right now. I feel like it's better to start with a simpler API and evolve it over time if needed.
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.
My current feeling (and your comment confirms that) is that it is not the final API and furthermore it is specific to
disjoint_pool
implementation.So why we cannot keep with the current approach when we pass just the list of memory providers and rely on the order of providers in that list?
I am worried because our goal was to upstream UMF as a part of UR but make API generic enough so that we can refer to it during discussions with other potential customers of the future standalone solution. Now it looks like we are making it USM (or
disjoint_pool
) specific.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.
We don't strictly need the interface to pass multiple memory providers to the memory pool right now. Even for metadata provider, it was mostly a 'future-looking' feature - the idea was that we could use it in DisjointPool (or any other) pool implementation, but we don't really use it right now (we just use regular new/delete).
As Piotr said, we should probably avoid implementing things we don't need to, perhaps for now, just having a single memory provider is enough - even without the metadata one (since we don;t have any implementation that would use it.)
I can revert the whole change that introduced the list of memory providers and just keep a single provider as it was originally. I would actually prefer that over defining which provider should be on position 0 or 1 in the list, etc. as that can change over time and we might silently break some (probably PoC) implementation silently - with function signature change, there would at least be a compilation error.
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.
So, I think it's just a question: do we think that having separate data and metadata memory provider is useful (and generic enough) or we'd rather wait for an actual implementation that will want to leverage that distinction.
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 agree with that.
Sounds like we came up to the conclusion that the current pool creation API and the proposed one in this PR are not required by the current UR implementation. Because
disjoint_pool
does not use the second memory provider today. Do we want to extenddisjoint_pool
to use "metadata" memory provider? If so, then the pool creation API should be able to accept more than one memory provider. But I think that this PR should be independant from #640.My current feeling is that #640 is more important and first we should address the native error handling use case. And I think error handling should not depend on how the pool is created. Otherwise, native error handling will depend on the Pool creation API and whenever we change the pool creation API the client code for native error handling is also impacted.
We can discuss it by call. In general, we agreed in the past that API and/or architectural changes should be discussed prior to actual code changes.