On Thu, Jul 4, 2013 at 1:56 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > On Wed, Jul 03, 2013 at 06:31:56PM -0700, Colin Cross wrote: >> Userspace processes often have multiple allocators that each do >> anonymous mmaps to get memory. When examining memory usage of >> individual processes or systems as a whole, it is useful to be >> able to break down the various heaps that were allocated by >> each layer and examine their size, RSS, and physical memory >> usage. > > So why not 'abuse' deleted files? > That's effectively what ashmem does for this use case, but it has its issues when allocators ask the kernel for memory multiple times. There are two ways to implement it in userspace, either reusing the same fd or using a new fd for every allocation. Using a new fd results in mappings that cannot be merged. In one example process in Android (system_server) this resulted in doubling the number of vmas used, which is far more expensive than the single pointer and refcounting added by this patch, and in another process (GLBenchmark) resulted in 16000 individual mappings, each with assocated vma, struct file, and refcounting. Reusing the same fd fundamentally changes the semantics of the memory. It requires the allocator to keep a global fd and offset variable, and extend the file and map the new region to get the kernel to merge the mappings. This inherently ties the memory together - AFAICT the kernel will not reclaim any of the memory until either the whole file is unmapped and the fd is closed, or userspace manually calls MADV_REMOVE. It's not immediately clear from the madvise man page what would happen after a fork if one process calls MADV_REMOVE on MAP_PRIVATE tmpfs memory, but if it really goes directly to the backing store won't those pages disappear for both processes? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>