On 07/05/2013 01:25 PM, Colin Cross wrote: > 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. Does mremap() help for expanding/shrinking the mappings? If you mmap()'d the middle of a large, deleted tmpfs file, you should be able to expand the VMA either up or down by quite a bit. > 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. The checkpoint/restart folks had some patches to let you get access to file descriptors which were closed but were used to mmap() something. I don't know where those went, but you'd be able to turn a mmap()'d address in to a fd with them, I believe. > 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. Huh? The kernel can reclaim mapped userspace memory just fine whether it's anonymous (or tmpfs) or file-backed. tmpfs is treated very similarly to swappable anonymous memory in this respect. > 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? MAP_PRIVATE means "divorced from the backing store". MADV_REMOVE only affects the caller's address space. -- 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>