-
Notifications
You must be signed in to change notification settings - Fork 17
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
CP013: Affinity asymmetry between execution and memory resource #41
Comments
We decided to adopt a new approach to representing the system topology where there is a separate topology structure for execution resources and for memory resources. For this we will need to split out the current One concern that we may need to consider is that the term memory resource may conflict with the existing pmr memory resource. |
On the other hand,
|
I was actually thinking that as well that we could used the |
Sorry I missed Monday's meeting! I'm a bit confused about why the memory resource type itself needs to be iterable. Why wouldn't one just call a function on a memory resource, to get the range of its subordinate resources? Why would the memory resource itself need begin() and end() instance methods? |
The reason I ask is that this would, as observed above, require using a subclass of a |
I get it now -- as long as the resource is a subclass of |
However, we did bring up an issue today, that since there's no "memory context," the system could unload a driver when the execution context goes away, and thus break extant memory allocations. |
Need a lifetime for memory -- e.g., "memory context" |
A "context" for a memory resource is an "allocator" |
@hcedwar I see -- that makes more sense now. This would mean users would create an allocator from a memory resource. Thanks! See discussion here about execution resource lifetime. It should also be relevant to memory resources, if one replaces "context" with "allocator." |
* Fixes codeplaysoftware#41 and codeplaysoftware#42. * Introduce `memory_resource` to represent the memory component of a system topology. * Remove `can_place_memory` and `can_place_agents` from the `execution_resource` as these are no longer required. * Remove `memory_resource` and `allocator` from the `execution_context` as these no longer make sense. * Update the wording to describe how execution resources and memory resources are structured. * Refactor `affinity_query` to be between an `execution_resource` and a `memory_resource`. * Make minor corrections.
Issue #41: Separate execution and memory resources
The Affinity
execution_context
has asymmetry in that it is constructed from an execution resource but supplies a memory resource. Should relationship be between execution resources and memory resources without an intervening execution context?The text was updated successfully, but these errors were encountered: