From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752859AbcISTcn (ORCPT ); Mon, 19 Sep 2016 15:32:43 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:36352 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752636AbcISTcm (ORCPT ); Mon, 19 Sep 2016 15:32:42 -0400 Date: Mon, 19 Sep 2016 21:32:38 +0200 From: Michal Hocko To: Robert Foss Cc: Sonny Rao , 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 Subject: Re: [PATCH v5 0/3] mm, proc: Implement /proc//totmaps Message-ID: <20160919193238.GA28639@dhcp22.suse.cz> 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> <0769f0c7-7869-2b0f-faac-3b5cbdb6e401@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0769f0c7-7869-2b0f-faac-3b5cbdb6e401@collabora.com> 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 19-09-16 11:16:31, Robert Foss wrote: > On 2016-09-14 05:12 AM, Michal Hocko wrote: > > On Tue 13-09-16 13:27:39, Sonny Rao wrote: [...] > > > 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? yes basically return the same value if called within HZ or something similar. But that assumes that statm latency really matters and it is called often enough. -- Michal Hocko SUSE Labs