From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx151.postini.com [74.125.245.151]) by kanga.kvack.org (Postfix) with SMTP id 0BD566B0033 for ; Fri, 5 Jul 2013 12:57:56 -0400 (EDT) Date: Fri, 5 Jul 2013 18:52:26 +0200 From: Oleg Nesterov Subject: Re: [PATCH] mm: add sys_madvise2 and MADV_NAME to name vmas Message-ID: <20130705165226.GA17120@redhat.com> References: <1372901537-31033-1-git-send-email-ccross@android.com> <87txkaq600.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Colin Cross Cc: "Eric W. Biederman" , 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 , Peter Zijlstra , Rusty Russell , 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 07/03, Colin Cross wrote: > > On Wed, Jul 3, 2013 at 9:54 PM, Eric W. Biederman wrote: > > Colin Cross writes: > > > > What is the advantage of this? It looks like it is going to add cache > > line contention (atomic_inc/atomic_dec) to every vma operation > > especially in the envision use case of heavy vma_name sharing. > > > > I would expect this will result in a bloated vm_area_struct and a slower > > mm subsystem. > > The advantage is better tracking of the impact of various userspace > allocations on the overall system. Userspace could track allocations > on its own, but it cannot track things like physical memory usage or > Kernel SamePage Merging per allocation. What I can't understand completely is why do you need the string to mark the vma's. Just make it "unsigned long vm_id" and avoid all these complications with get/put and "struct vma_name". And afaics you can avoid other complications too, the new argumnent for vma_merge() is not really needed. This patch would be trivial. > I expect "hand break" is overstating the impact. The code complexity (and even size) does matter too ;) It is not clear if this new feature worth the trouble. Oleg. -- 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