From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx157.postini.com [74.125.245.157]) by kanga.kvack.org (Postfix) with SMTP id B87B26B0036 for ; Fri, 5 Jul 2013 16:25:46 -0400 (EDT) Received: by mail-ve0-f174.google.com with SMTP id oz10so2100249veb.19 for ; Fri, 05 Jul 2013 13:25:45 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20130704085604.GI18898@dyad.programming.kicks-ass.net> References: <1372901537-31033-1-git-send-email-ccross@android.com> <20130704085604.GI18898@dyad.programming.kicks-ass.net> Date: Fri, 5 Jul 2013 13:25:45 -0700 Message-ID: Subject: Re: [PATCH] mm: add sys_madvise2 and MADV_NAME to name vmas From: Colin Cross Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Peter Zijlstra Cc: 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 list:DOCUMENTATION" , "open list:MEMORY MANAGEMENT" , "open list:GENERIC INCLUDE/A..." 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. 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@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org