From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx167.postini.com [74.125.245.167]) by kanga.kvack.org (Postfix) with SMTP id 6BEC76B0032 for ; Wed, 10 Jul 2013 19:20:56 -0400 (EDT) Message-ID: <51DDEC52.7010005@intel.com> Date: Wed, 10 Jul 2013 16:20:50 -0700 From: Dave Hansen MIME-Version: 1.0 Subject: Re: [PATCH] mm: add sys_madvise2 and MADV_NAME to name vmas References: <1372901537-31033-1-git-send-email-ccross@android.com> <20130704085604.GI18898@dyad.programming.kicks-ass.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Colin Cross Cc: Peter Zijlstra , lkml , Kyungmin Park , Christoph Hellwig , John Stultz , Rob Landley , Arnd Bergmann , Andrew Morton , Cyrill Gorcunov , David Rientjes , Davidlohr Bueso , Kees Cook , Al Viro , Hugh Dickins , Mel Gorman , Michel Lespinasse , Rik van Riel , Konstantin Khlebnikov , Rusty Russell , "Eric W. Biederman" , Oleg Nesterov , Srikar Dronamraju , KAMEZAWA Hiroyuki , Michal Hocko , Anton Vorontsov , Pekka Enberg , Shaohua Li , Sasha Levin , KOSAKI Motohiro , Johannes Weiner , Ingo Molnar , open@kvack.org, list@kvack.org, DOCUMENTATION open@kvack.orglist@kvack.org, MEMORY MANAGEMENT , "open list:GENERIC INCLUDE/A..." On 07/05/2013 01:25 PM, Colin Cross wrote: > On Thu, Jul 4, 2013 at 1:56 AM, Peter Zijlstra 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@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org