You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a GNU extension, but it seems a lot of other allocators support it as well. It would be useful to have in e.g. system wide low-memory conditions.
The text was updated successfully, but these errors were encountered:
The question is how aggressive it should be. It can only work on the calling thread cache and possibly the global cache. Should it empty and unmap both, or just the thread cache? Perhaps interpret the pad argument as
If argument is zero - empty and unmap both thread and global cache
If argument is non-zero - empty the thread cache (possibly leaving the number of spans matching the size given) and not touching global cache
It can only work on the calling thread cache and possibly the global cache.
Is there no way to (atomically) release the free spans from other caches? Otherwise it would not be very useful on systems like Haiku, where processes usually have 4-6 threads at a minimum, and usually more.
Unfortunately not, a lot o the performance in rpmalloc and similar, like mimalloc and tcmalloc, comes from that the thread heap is known to be touched only by the owning heap (except for the cross-thread deferred free list).
Of course the thread cache lists could be changed to use atomics and sacrifice some performance which would allow a trim method to walk all heaps and release them. I'll think about adding a compile time option for this.
http://man7.org/linux/man-pages/man3/malloc_trim.3.html
This is a GNU extension, but it seems a lot of other allocators support it as well. It would be useful to have in e.g. system wide low-memory conditions.
The text was updated successfully, but these errors were encountered: