-
Notifications
You must be signed in to change notification settings - Fork 3.7k
[VM] Memory Manager moved up to runtime #15833
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
6562464 to
3f8b8ae
Compare
4dc673b to
60fa956
Compare
yongwww
left a comment
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.
Thanks for the work, overall it looks good to me, have left some comments.
yongwww
left a comment
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.
LGTM
echuraev
left a comment
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.
In general LGTM. Thank you for your PR! One comment which should be applied.
36b9112 to
98fa479
Compare
Now graph runtime also uses the same memory manager This acommodates a common memory manager with pooled and naive support. As a follow up we can move the WorkspacePool to use this common memory manager.
Co-authored-by: Egor Churaev <egor.churaev@gmail.com>
Using available allocator instead of requested is leading to an unpexpected crash
98fa479 to
b1ee28f
Compare
|
This was merged, thanks for the effort! |
* [VM] memory Manager moved up to runtime Now graph runtime also uses the same memory manager This acommodates a common memory manager with pooled and naive support. As a follow up we can move the WorkspacePool to use this common memory manager. * * update dependents with new file addition. * * define memory_manager under new namespace * * use ShapeTuple across vm executor and memory_manager * * ShapeTuple across the Allocators * * GetDataSize is moved to DeviceAPI and memory_manager uses this interface. * * review comments * * Make compiler happy with unused variables * * lint * Update src/runtime/memory/memory_manager.cc Co-authored-by: Egor Churaev <egor.churaev@gmail.com> * * allow multiple allocators to coexist for the same device. Using available allocator instead of requested is leading to an unpexpected crash --------- Co-authored-by: Egor Churaev <egor.churaev@gmail.com>
Now graph runtime also uses the same memory manager This acommodates a common memory manager with pooled and naive support.
As a follow up we can move the WorkspacePool to use this common memory manager.
This is a prerequisite to accommodate a common two stage memory allocation as described in #15058