From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 629B9C43461 for ; Fri, 21 May 2021 04:17:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DBCDE61353 for ; Fri, 21 May 2021 04:17:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DBCDE61353 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 251D7940011; Fri, 21 May 2021 00:17:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2156A94000D; Fri, 21 May 2021 00:17:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0CA77940011; Fri, 21 May 2021 00:17:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0089.hostedemail.com [216.40.44.89]) by kanga.kvack.org (Postfix) with ESMTP id D111394000D for ; Fri, 21 May 2021 00:17:36 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5EE56C5D9 for ; Fri, 21 May 2021 04:17:36 +0000 (UTC) X-FDA: 78163929312.17.1A79D6E Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf01.hostedemail.com (Postfix) with ESMTP id 615285001649 for ; Fri, 21 May 2021 04:17:33 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E6828101E; Thu, 20 May 2021 21:17:32 -0700 (PDT) Received: from [192.168.0.130] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C5F2E3F719; Thu, 20 May 2021 21:17:30 -0700 (PDT) Subject: Re: [PATCH] mm/thp: Update mm_struct's MM_ANONPAGES stat for huge zero pages To: Hugh Dickins Cc: Andrew Morton , Zi Yan , Yang Shi , "Kirill A. Shutemov" , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <1621313300-1118-1-git-send-email-anshuman.khandual@arm.com> From: Anshuman Khandual Message-ID: <8fa7fea6-4176-32fd-2c6a-abb6b73d0d13@arm.com> Date: Fri, 21 May 2021 09:48:11 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf01.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 615285001649 X-Stat-Signature: aridphe19z87gbpu3mh7ziwbfy7n7k56 X-HE-Tag: 1621570653-799719 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 5/21/21 7:47 AM, Hugh Dickins wrote: > On Tue, 18 May 2021, Anshuman Khandual wrote: > >> Although the zero huge page is being shared across various processes, each >> mapping needs to update its mm_struct's MM_ANONPAGES stat by HPAGE_PMD_NR >> to be consistent. This just updates the stats in set_huge_zero_page() after >> the mapping gets created and in zap_huge_pmd() when mapping gets destroyed. >> >> Cc: Andrew Morton >> Cc: Zi Yan >> Cc: linux-mm@kvack.org >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: Anshuman Khandual > > NAK. > > For consistency with what? In the all the years that the huge zero page Huge zero page after all is an anon mapping. Hence why it must not be counted for process rss MM_ANONPAGES accounting ? Is there a specific reason why zero huge pages should not counted for MM_ANONPAGES ? Does not it risk an inaccurate MM_ANONPAGES accounting for the processes using huge zero pages ? > has existed, it has been intentionally exempted from rss accounting: > consistent with the small zero page, which itself has always been > intentionally exempted from rss accounting. In fact, that's a good part Why are small zero pages exempted from rss accounting which in turn might have caused huge zero page to take the same approach as well ? > of the reason the huge zero page was introduced (see 4a6c1297268c). Huge zero page reduces memory consumption on read faults which is a definite advantage but would there be a problem if rss stat goes up for each huge zero page mapping instances. The commit mentioned here talks about increase in actual memory utilization as seen from the rss accounting stat, without huge zero page usage. I am wondering if actual memory usage remains the same (reduced with huge zero page usage), what could be the problem in an increased MM_ANONPAGES accounting for a given process. Dont we update the rss accounting for shared memory as well ? > > To change that now will break any users depending on it. Just to understand it correctly, are rss accounting procedures/methods something which cannot be changed as users are currently dependent on it ? OR this proposal here is not a good enough reason to change it ? > > Not to mention the > BUG: Bad rss-counter state mm:00000000aa61ef82 type:MM_ANONPAGES val:512 > I just got from mmotm. Okay, unfortunately some how did not see this problem while testing. Is there a specific test case which will be able to trigger this bug ? - Anshuman