I am using the latest Windows Intel TBB 2018 Update 2, and am struggling getting the TBB allocators to release memory.
My application has a peak usage of say 25GB.
When using the tbb::allocator the "working set" will peak to 25GB and stay there as , even when all objects are deallocated.
When using the std::allocator the memory will also peak to 25GB but will drop back down to the expected level of 2GB when all objects are deallocated.
I realize that the TBB memory is caching and does not release memory back to the OS, and that is why it outperforms std::allocator
However, I am explicitly calling , at a specific point in my code when memory should be recovered,
but this seems to have no effect despite returning 0. Maybe I am missing something here but it seems that there really should be a way to force TBB to return all deallocated memory to the OS reliably.
seems to describe the issue pretty well, and the problems I am facing. It appears nothing has been done to address the issue
There are could be issues with cleaning the memory which was freed from other threads, and we are currently working on different ways of memory footprint decreasing. It would be very helpful if you can send us a reproducer of your situation for deeper analysis.
I have been thinking about this issue. If, as I assume, the TBB allocator allocates blocks of memory from the OS then a particular block can only be returned to the OS when it has no more references to it ( all references de-allocated). That is application specific and depends on the pattern of allocations/deallocations.
In my case, using a tbb::memory_pool and making sure all my allocations come from that pool was the solution to dealing with sudden peak usage. When done I can delete the memory_pool.