From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754132AbbAWA2k (ORCPT ); Thu, 22 Jan 2015 19:28:40 -0500 Received: from mail-qa0-f46.google.com ([209.85.216.46]:32929 "EHLO mail-qa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752570AbbAWA2j (ORCPT ); Thu, 22 Jan 2015 19:28:39 -0500 MIME-Version: 1.0 In-Reply-To: References: <20150107172452.GA7922@node.dhcp.inet.fi> <20150114152225.GB31484@google.com> <20150114233630.GA14615@node.dhcp.inet.fi> Date: Fri, 23 Jan 2015 00:28:38 +0000 X-Google-Sender-Auth: ZlN7MLkjbdRvx6yilkfdAouOQ4o Message-ID: Subject: Re: [PATCH v2 2/2] task_mmu: Add user-space support for resetting mm->hiwater_rss (peak RSS) From: Primiano Tucci To: David Rientjes Cc: "Kirill A. Shutemov" , Petr Cermak , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Bjorn Helgaas , Hugh Dickins Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 22, 2015 at 11:27 PM, David Rientjes wrote: > If you reset the hwm for a process, rss grows to 100MB, another process > resets the hwm, and you see a hwm of 2MB, that invalidates the hwm > entirely. Not sure I follow this scenario. Where does the 2MB come from? How can you see a hwm of 2MB, under which conditions? HVM can never be < RSS. Again, what you are talking about is the case of two profilers racing for using the same interface (hwm). This is the same case today of the PG_referenced bit. > The hwm is already defined as the > highest rss the process has attained, resetting it and trying to make any > inference from the result is racy and invalidates the actual value which > is useful. The counter arugment is: once you have one very high peak, the hvm becomes essentially useless for the rest of the lifetime of the process (until a higher peak comes). This makes very hard to understand what is going on in the meanwhile (from userspace). Anyways, are you proposing to pursue a different approach? Is the approach 2. that petrcermark@ proposed in the beginning of the thread going to address this concern? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by kanga.kvack.org (Postfix) with ESMTP id 3FACC6B0032 for ; Thu, 22 Jan 2015 19:28:39 -0500 (EST) Received: by mail-qc0-f173.google.com with SMTP id m20so4145181qcx.4 for ; Thu, 22 Jan 2015 16:28:39 -0800 (PST) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com. [2607:f8b0:400d:c01::234]) by mx.google.com with ESMTPS id y97si6763558qgd.60.2015.01.22.16.28.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jan 2015 16:28:38 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id r5so4128996qcx.11 for ; Thu, 22 Jan 2015 16:28:38 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20150107172452.GA7922@node.dhcp.inet.fi> <20150114152225.GB31484@google.com> <20150114233630.GA14615@node.dhcp.inet.fi> Date: Fri, 23 Jan 2015 00:28:38 +0000 Message-ID: Subject: Re: [PATCH v2 2/2] task_mmu: Add user-space support for resetting mm->hiwater_rss (peak RSS) From: Primiano Tucci Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes Cc: "Kirill A. Shutemov" , Petr Cermak , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Bjorn Helgaas , Hugh Dickins On Thu, Jan 22, 2015 at 11:27 PM, David Rientjes wrote: > If you reset the hwm for a process, rss grows to 100MB, another process > resets the hwm, and you see a hwm of 2MB, that invalidates the hwm > entirely. Not sure I follow this scenario. Where does the 2MB come from? How can you see a hwm of 2MB, under which conditions? HVM can never be < RSS. Again, what you are talking about is the case of two profilers racing for using the same interface (hwm). This is the same case today of the PG_referenced bit. > The hwm is already defined as the > highest rss the process has attained, resetting it and trying to make any > inference from the result is racy and invalidates the actual value which > is useful. The counter arugment is: once you have one very high peak, the hvm becomes essentially useless for the rest of the lifetime of the process (until a higher peak comes). This makes very hard to understand what is going on in the meanwhile (from userspace). Anyways, are you proposing to pursue a different approach? Is the approach 2. that petrcermark@ proposed in the beginning of the thread going to address this concern? -- 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