Memory allocated using scalable_malloc is never returned to OS.

[alexhe]

Read an article at http://www.intel.com/technology/itj/2007/v11i4/5-foundations/5-memory.htmtalked about tbb scalable allocator. Itstates that "requested memory is never returned to OS". I am wondering if it is possible in the future we could return some memory back to OSso other process could reuse them. Currently, if I allocate many small objects and then free them up, the memory is still held by global heap.

[RafSchietekat]

"return some memory back to OS so other process could reuse them" TBB will not take memory away from other processes, it will just make that virtual memory (not even real memory) unavailable for other uses within the same process (like mapping a file). It would be difficult to get it to return memory because of fragmentation: any tiny allocation is capable to keep the 1-MB chunk in which it is located pinned down and unavailable for anything else. That's not to say nothing can ever be done, but any relief will likely be minor, so if you've got a very big application, i.e., one that uses multiple gigabytes of memory, you might want to start thinking about moving to 64 bits, but otherwise you probably needn't worry about this.

[RafSchietekat]

(Added) Well, there is still the swap file... I don't think there are (m)any operating systems that compress swap files (although with current processor speeds it might not even be a bad idea to swap compressed pages out to... RAM, and only then to disk), but maybe they already do something special for memory pages that were wiped clean? Otherwise, I think I might (need to) try something with something like madvise(MADV_FREE). Any O.S. buffs out there with even better advice (pun intended), before I start on this?

[alexhe]

Quoting - Raf Schietekat

"return some memory back to OS so other process could reuse them" TBB will not take memory away from other processes, it will just make that virtual memory (not even real memory) unavailable for other uses within the same process (like mapping a file). It would be difficult to get it to return memory because of fragmentation: any tiny allocation is capable to keep the 1-MB chunk in which it is located pinned down and unavailable for anything else. That's not to say nothing can ever be done, but any relief will likely be minor, so if you've got a very big application, i.e., one that uses multiple gigabytes of memory, you might want to start thinking about moving to 64 bits, but otherwise you probably needn't worry about this.

This this the senario I am considering: At the peak time, my server handles 5000 sessions and 500MB memory is allocated. After the peak, there are only 500 live sessions and requires only 50MB memory, but with TBB memory allocator enabled, the server still holds 500MB. So, I want to have a housekeeping thread and it checks if the server is not busy, free up some memory (use a heuristic function). Yes, I know there is fragmentation concerns, but I assume as long as we allocate memory in big chunks (say 1MB), fragmentation issue is minor (correct me if I am wrong).

[RafSchietekat · Accepted solution]

"the server still holds 500MB" If you see 500 MB for a process when you know that it doesn't need all this memory, then you still don't have cause for immediate concern, because this memory can be swapped out so that the RAM can be used for something else: you might see virtual-memory use remain at this high level, but real-memory use should drop. It may not be elegant, and it may give rise to some needless disk activity, but are you sure it's a real problem? Are you using this computer for a dance where other processes repeatedly need exactly the memory that TBB didn't free?

"I assume as long as we allocate memory in big chunks (say 1MB), fragmentation issue is minor (correct me if I am wrong)" Allocation requests above about 8 kB are delegated to malloc() (with a sometimes considerable alignment overhead), but afterwards the memory is also fully released to free(). TBB quite efficiently allocates the smaller sizes itself from 1-MB chunks it typically obtains from mmap() (not from the heap), and those are never released; the bigger the chunks would be, the higher the chances that there would be live memory somewhere inside them preventing their release even if TBB were to support that.