From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757384AbcH3IPn (ORCPT ); Tue, 30 Aug 2016 04:15:43 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:35673 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757111AbcH3IPh (ORCPT ); Tue, 30 Aug 2016 04:15:37 -0400 Date: Tue, 30 Aug 2016 10:15:34 +0200 From: Michal Hocko To: Sonny Rao Cc: Jann Horn , Robert Foss , Jonathan Corbet , Andrew Morton , Vlastimil Babka , Konstantin Khlebnikov , Hugh Dickins , Naoya Horiguchi , Minchan Kim , John Stultz , ross.zwisler@linux.intel.com, jmarchan@redhat.com, Johannes Weiner , Kees Cook , Al Viro , Cyrill Gorcunov , Robin Humble , David Rientjes , eric.engestrom@imgtec.com, Janis Danisevskis , calvinowens@fb.com, Alexey Dobriyan , "Kirill A. Shutemov" , ldufour@linux.vnet.ibm.com, linux-doc@vger.kernel.org, "linux-kernel@vger.kernel.org" , Ben Zhang , Bryan Freed , Filipe Brandenburger , Mateusz Guzik Subject: Re: [PACTH v2 0/3] Implement /proc//totmaps Message-ID: <20160830081533.GA23963@dhcp22.suse.cz> References: <20160818074433.GC30162@dhcp22.suse.cz> <20160818180104.GS30162@dhcp22.suse.cz> <20160819075910.GB32619@dhcp22.suse.cz> <20160822075429.GD13596@dhcp22.suse.cz> <20160829143704.GE2968@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160829143704.GE2968@dhcp22.suse.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 29-08-16 16:37:04, Michal Hocko wrote: > [Sorry for a late reply, I was busy with other stuff] > > On Mon 22-08-16 15:44:53, Sonny Rao wrote: > > On Mon, Aug 22, 2016 at 12:54 AM, Michal Hocko wrote: > [...] > > But what about the private_clean and private_dirty? Surely > > those are more generally useful for calculating a lower bound on > > process memory usage without additional knowledge? > > I guess private_clean can be used as a reasonable estimate. I was thinking about this more and I think I am wrong here. Even truly MAP_PRIVATE|MAP_ANON will be in private_dirty. So private_clean will become not all that interesting and similarly misleading as its _dirty variant (mmaped file after [m]sync should become _clean) and that doesn't mean the memory will get freed after the process which maps it terminates. Take shmem as an example again. > private_dirty less so because it may refer to e.g. tmpfs which is not > mapped by other process and so no memory would be freed after unmap > without removing the file. -- Michal Hocko SUSE Labs