-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[CPU] Add interface to release compiled model internal memory #26262
[CPU] Add interface to release compiled model internal memory #26262
Conversation
* @brief Release intermediate memory | ||
* | ||
*/ | ||
virtual void release_buffers(); |
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.
Think about a better name. This one doens't really clarify which buffers are really implied.
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 several requests are still running and I will call this method?
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 is a really good question. This is merely a POC to evaluate the memory footprint in a specific application. So the exact interface level solution is a subject of an arch review.
GraphGuard::Lock graph_lock{graph}; | ||
auto ctx = graph_lock._graph.getGraphContext(); | ||
ctx->getNetworkMemoryControl()->releaseMemory(); | ||
} |
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.
Should we add releasing the oneDNN caches here?
dnnl::engine eng; | ||
|
||
public: | ||
DnnlScratchPad(const dnnl::engine& eng, int numa_node = -1) : eng(eng) { | ||
mgrPtr = std::make_shared<DnnlMemoryMngr>(make_unique<MemoryMngrWithReuse>(numa_node)); | ||
blockPtr = std::make_shared<DnnlMemoryBlock>(make_unique<MemoryBlockWithReuse>(numa_node)); |
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.
Should be created by the memory control subsystem to be released on demand also. But it may require shotgun surgery to cover all the existing cases of direct scratchpad using (when the implementation bypasses the getSchrachpadMemory
call.
void insertReorder(EdgePtr& edge, bool isOptimized, std::unordered_set<std::string>& uniqueLayerNames); | ||
void insertConvert(EdgePtr& edge); | ||
int GetNumaNodeId() const; | ||
MemoryControl* m_pMemoryControl = nullptr; |
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's meaningful to change ptr to ref, but to this end a few MemoryControl
methods must be modified as well.
|
||
private: | ||
MemoryControl::MemoryBlockMap m_blocks; | ||
std::vector<MemorySolver::Box> m_boxes; |
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.
May be it makes sense to use FIFO buffer?
// TODO: conceptually fetchRawMemory is a very bad solution | ||
if (mem->getDesc().getPrecision() == element::string) { | ||
return; | ||
} | ||
auto block = mem->getMemoryBlock(); | ||
if (mem->isDefined()) { | ||
block->resize(mem->getSize()); | ||
} |
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.
Possible solutions:
allocate()
for the memory interface. The main drawback is that the memory with such an interface don't have to allocate memory in constructor, which brings additional complexity:allocated()
check and subsequent mandatoryallocate()
call, which obviously is extra work for the user.- lazy evaluation inside
getData()
. There are two problems, the first one is that in this case thegetData
call wouldn't be constant anymore thereby wouldn't be thread safe. Another problem is that some implementations still use dnnl memory object instead of the plugin entities, thus they wouldn't callgetData
and wouldn't trigger memory reallocation.
Probably we need another solution.
Details:
Port #26390 to master
Tickets: