From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752187AbcISPQo (ORCPT ); Mon, 19 Sep 2016 11:16:44 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:56536 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750745AbcISPQl (ORCPT ); Mon, 19 Sep 2016 11:16:41 -0400 Subject: Re: [PATCH v5 0/3] mm, proc: Implement /proc//totmaps To: Michal Hocko , Sonny Rao References: <1473106449-12847-1-git-send-email-robert.foss@collabora.com> <20160912120248.GK14524@dhcp22.suse.cz> <20160912171503.GB14997@dhcp22.suse.cz> <20160913071208.GC31898@dhcp22.suse.cz> <20160914091205.GD1612@dhcp22.suse.cz> Cc: Jonathan Corbet , Andrew Morton , Vlastimil Babka , Hugh Dickins , Konstantin Khlebnikov , Naoya Horiguchi , "Kirill A. Shutemov" , John Stultz , Minchan Kim , ross.zwisler@linux.intel.com, jmarchan@redhat.com, Johannes Weiner , Kees Cook , oleg@redhat.com, Al Viro , Mateusz Guzik , Janis Danisevskis , calvinowens@fb.com, Alexey Dobriyan , ebiederm@xmission.com, Seth Forshee , Djalal Harouni , linux-doc@vger.kernel.org, "linux-kernel@vger.kernel.org" , Ben Zhang , Bryan Freed , Filipe Brandenburger , Jann Horn , linux-api@vger.kernel.org, Jacek Anaszewski From: Robert Foss Message-ID: <0769f0c7-7869-2b0f-faac-3b5cbdb6e401@collabora.com> Date: Mon, 19 Sep 2016 11:16:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160914091205.GD1612@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016-09-14 05:12 AM, Michal Hocko wrote: > On Tue 13-09-16 13:27:39, Sonny Rao wrote: >> On Tue, Sep 13, 2016 at 12:12 AM, Michal Hocko wrote: >>> On Mon 12-09-16 10:28:53, Sonny Rao wrote: >>>> On Mon, Sep 12, 2016 at 10:15 AM, Michal Hocko wrote: >>>>> On Mon 12-09-16 08:31:36, Sonny Rao wrote: >>> [...] >>>>>> but how about the other fields like Swap, Private_Dirty and >>>>>> Private_Shared? >>>>> >>>>> Private_Shared can be pretty confusing as well without the whole context >>>>> as well see my other emails in the original thread (just to remind >>>>> shmem/tmpfs makes all this really confusing). >>>> >>>> But this is exactly the issue -- RSS is can be just as confusing if >>>> you don't know something about the application. >>> >>> I agree that rss can be confusing but we will not make the situation any >>> better if we add yet another confusing metric. >>> >>>> I think the issue is >>>> how common that situation is, and you seem to believe that it's so >>>> uncommon that it's actually better to keep the information more >>>> difficult to get for those of us who know something about our systems. >>>> >>>> That's fine, I guess we just have to disagree here, thanks for look at this. >>> >>> I think you should just step back and think more about what exactly >>> you expect from the counter(s). I believe what you want is an >>> estimate of a freeable memory when the particular process dies or is >>> killed. That would mean resident single mapped private anonymous memory >>> + unlinked single mapped shareable mappings + single mapped swapped out >>> memory. Maybe I've missed something but it should be something along >>> those lines. Definitely something that the current smaps infrastructure >>> doesn't give you, though. >> >> Yes your description of what we want is pretty good. Having a >> reasonable lower bound on the estimate is fine, though we probably >> want to break out swapped out memory separately. > > Why would you want to separate that? > >> Given that smaps >> doesn't provide this in a straightforward way, what do you think is >> the right way to provide this information? > > I would be tempted to sneak it into /proc//statm because that looks > like a proper place but getting this information is not for free > performance wise so I am not really sure something that relies on this > file would see unexpected stalls. Maybe this could be worked around by > some caching... I would suggest to check who is actually using this file > (top/ps etc...) What would this caching look like? Can any information be re-used between vma walks? > > If this would be unacceptable then a new file could be considered. >