2 ms·

> Having a lot of virtual memory does not "cost" much To some extent, I agree, at least on 64 bit systems (on 32 bit systems, there was the risk of running out

> Having a lot of virtual memory does not "cost" much To some extent, I agree, at least on 64 bit systems (on 32 bit systems, there was the risk of running out of address space). However, the memory in question here is, for the most part, not freshly allocated, but was in use once. This means that it used to be backed by physical memory, and before that backing can be withdrawn, the page has to be written to disk. It seems to me that the best solution would be to call madvise(MADV_FREE) on these regions, in which case they can be unbacked without further ado. I'm somewhat surprised that the memory allocator does not do this itself already.

the8472 8y ago
That's what jemalloc does (besides avoiding fragmentation) and one of the reasons why people use it. http://jemalloc.net/jemalloc.3.html#opt.dirty_decay_ms http://jemalloc.net/jemalloc.3.html#opt.dirty_decay_ms
scott_s 8y ago
> However, the memory in question here is, for the most part, not freshly allocated, but was in use once. Because the author does not differentiate between virtual and physical memory, I can’t agree with that. It’s quite possible most of the memory “freed” was never in use. In which case, there’s not much benefit. And there is the probable downside that allocation heavy applications will pay a lot more.
- microtherion 8y ago
  > It’s quite possible most of the memory “freed” was never in use. Given the allocation patterns shown, it would seem to me that if two blocks are still in use, it's fairly likely that the region in between also were in use once (there may be exceptions due to pools etc, but generally memory is parcelled out in a linear fashion). > And there is the probable downside that allocation heavy applications will pay a lot more. What would the cost be? All that would happen is that the free pages are marked as clean. I'm sure that's not entirely free, but bound to be considerably cheaper than paging the page out and in again.
  - scott_s 8y ago
    > What would the cost be? All that would happen is that the free pages are marked as clean. That's a minor page fault. You get an OS-level exception, switch to kernel mode, process the page fault by marking the page as loaded, then switching back to user mode. That is expensive if you do it a lot. > but bound to be considerably cheaper than paging the page out and in again. Yes, of course, a minor page fault is cheaper than a major page fault. But both are more expensive than no page fault, which is what happens if you just never free the page to the OS and there's plenty of available physical memory.

the8472 8y ago

That's what jemalloc does (besides avoiding fragmentation) and one of the reasons why people use it. http://jemalloc.net/jemalloc.3.html#opt.dirty_decay_ms http://jemalloc.net/jemalloc.3.html#opt.dirty_decay_ms

scott_s 8y ago

> However, the memory in question here is, for the most part, not freshly allocated, but was in use once. Because the author does not differentiate between virtual and physical memory, I can’t agree with that. It’s quite possible most of the memory “freed” was never in use. In which case, there’s not much benefit. And there is the probable downside that allocation heavy applications will pay a lot more.

microtherion 8y ago
> It’s quite possible most of the memory “freed” was never in use. Given the allocation patterns shown, it would seem to me that if two blocks are still in use, it's fairly likely that the region in between also were in use once (there may be exceptions due to pools etc, but generally memory is parcelled out in a linear fashion). > And there is the probable downside that allocation heavy applications will pay a lot more. What would the cost be? All that would happen is that the free pages are marked as clean. I'm sure that's not entirely free, but bound to be considerably cheaper than paging the page out and in again.
- scott_s 8y ago
  > What would the cost be? All that would happen is that the free pages are marked as clean. That's a minor page fault. You get an OS-level exception, switch to kernel mode, process the page fault by marking the page as loaded, then switching back to user mode. That is expensive if you do it a lot. > but bound to be considerably cheaper than paging the page out and in again. Yes, of course, a minor page fault is cheaper than a major page fault. But both are more expensive than no page fault, which is what happens if you just never free the page to the OS and there's plenty of available physical memory.