From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752427AbdJ0J0a (ORCPT ); Fri, 27 Oct 2017 05:26:30 -0400 Received: from mx2.suse.de ([195.135.220.15]:57573 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752103AbdJ0J02 (ORCPT ); Fri, 27 Oct 2017 05:26:28 -0400 Date: Fri, 27 Oct 2017 11:26:26 +0200 From: Michal Hocko To: "Du, Fan" Cc: "Hansen, Dave" , "akpm@linux-foundation.org" , "hch@lst.de" , "Williams, Dan J" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v4] Add /proc/PID/smaps support for DAX Message-ID: <20171027092626.evfc4ridlilxxvpb@dhcp22.suse.cz> References: <5A90DA2E42F8AE43BC4A093BF06788481AA50489@SHSMSX104.ccr.corp.intel.com> <1508994790-15427-1-git-send-email-fan.du@intel.com> <482dcf1c-6013-c800-3e95-7476b9e52020@intel.com> <5A90DA2E42F8AE43BC4A093BF06788481AA513E1@SHSMSX104.ccr.corp.intel.com> <20171027080730.3532fpgcwbozewfv@dhcp22.suse.cz> <5A90DA2E42F8AE43BC4A093BF06788481AA517B6@SHSMSX104.ccr.corp.intel.com> <20171027084233.dulvjusgxypwsts5@dhcp22.suse.cz> <5A90DA2E42F8AE43BC4A093BF06788481AA5188F@SHSMSX104.ccr.corp.intel.com> <20171027090919.g3aa2wuwacrl23oe@dhcp22.suse.cz> <5A90DA2E42F8AE43BC4A093BF06788481AA518EF@SHSMSX104.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A90DA2E42F8AE43BC4A093BF06788481AA518EF@SHSMSX104.ccr.corp.intel.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 27-10-17 09:17:07, Du, Fan wrote: [...] > >But you cannot touch rss and pss because you are going to break existing > >users as Dave already pointed out. > > Why it will break something? Do you mind to elaborate? > The vma part of each smaps portion has associated file if does exist, > The user spaces monitoring tools will definitely check this field. Because there are tools which evaluate rss and pss as the real _memory_ consumption. If you put non-ram based memory there you would confuse them and they would do wrong decisions. In fact we do not even include all the RAM based memory there. For example hugetlb pages are not involved and have their separate counter because there are tools which would misjudge processes with large hugetlb mapping - e.g. kill them as excessive consumers without any memory returned back to the system. While all this is really far from ideal, this is how the userspace work and we are not breaking existing usecases. -- Michal Hocko SUSE Labs