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=-12.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 B80EFC43460 for ; Thu, 13 May 2021 17:00:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 994B061442 for ; Thu, 13 May 2021 17:00:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230316AbhEMRBS (ORCPT ); Thu, 13 May 2021 13:01:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48754 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230164AbhEMRA5 (ORCPT ); Thu, 13 May 2021 13:00:57 -0400 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CEEAAC06175F for ; Thu, 13 May 2021 09:59:47 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id c22so12720223ejd.12 for ; Thu, 13 May 2021 09:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qlfKotu9sca7LHhOUQlejV4TMBT38h8R33rjxE+jdW8=; b=Zqr3iG+q0GJOewBqwZhZyyP9OMzSabGqlImo0bNoJVzWNtvVPzvEP4Eq5tNFu3YVCy GhfQsgXXr2hD2WSkbDSAM6y1eOseCYhVMPBgMO6rs9OZST5ITs6bRMSE2ooZzbHO6hcg yTWC/G33pE9f1kH7cxRgHRs0MeGiTmsciBFOhYqqSWjafMzr93SpShiV7tgEBi6bL43d aAbnvQ1uzcaqBNMOwwBveKW+jJn++qrSPPEhNd5fnyk+xjQDEzsQjFtXsazEimGRydJ9 FvAkDicbe8lru1funJlzYAkUsOtq7+jAUIwGBaspsNp6/Zmjr3J21Sv4wxQVxD+rD3To qhOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qlfKotu9sca7LHhOUQlejV4TMBT38h8R33rjxE+jdW8=; b=B6Sqo3P3KIL6BcRXe2uqg/ck+EGKuX+EeJo0aNiD+rAU/5kBY0vgxW4AzEt0XCzahg dwvfsvuGSj8KKl/giIxU7zYWhbjecbWH7sBNtPXe3XXQEAlZdTG2VPQQARD32bvR58YA zFjTWTOPpQTqOgukT73f+datJZtG9Q3DaAJZMzwaZ3qLl2EVbJKOhXf8qjrCBMFdZsTZ q7zu/mINpHW9VQohxnvl3IXNGPUJqGcV8QnmKPDDaEinw5AgMJEL/a7PLOTeX/VKqm7P 7nbZbYWhvDJDq34nC9/cLYiJ7AHsIXffuxEyKyEaBeDaTsUdefzSF2fggbOQtQ9ZREVh +q1A== X-Gm-Message-State: AOAM531Ra89AcHbdJ9OaV4olDPSuEsWXiqG389591NmNN/r61+nCE03E lzzCCxX5HEhBCUAeN3vMyOc5kFc6WZgX9iSVnOM= X-Google-Smtp-Source: ABdhPJwTw/EhzpOLvZKoM7wzshi7JIeiZlRD0pSH09UR1VbFoI380Mgzy6S0IYW9rB5Yrs2Pq87gtWFtP0E92gIExkE= X-Received: by 2002:a17:906:b7d6:: with SMTP id fy22mr1236673ejb.383.1620925186436; Thu, 13 May 2021 09:59:46 -0700 (PDT) MIME-Version: 1.0 References: <1620890438-9127-1-git-send-email-anshuman.khandual@arm.com> In-Reply-To: From: Yang Shi Date: Thu, 13 May 2021 09:59:34 -0700 Message-ID: Subject: Re: [RFC] mm/thp: Update mm's MM_ANONPAGES stat in set_huge_zero_page() To: Anshuman Khandual Cc: Linux MM , Andrew Morton , Zi Yan , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 13, 2021 at 9:50 AM Yang Shi wrote: > > On Thu, May 13, 2021 at 12:20 AM Anshuman Khandual > wrote: > > > > Although the zero huge page is being shared across various processes, each > > mapping needs to update its mm's MM_ANONPAGES stat by HPAGE_PMD_NR in order > > to be consistent. This just updates the stats in set_huge_zero_page() after > > the mapping gets created. > > I don't get why MM_ANONPAGES needs to be inc'ed when huge zero page is > installed. This may cause inconsistency between some counters, for > example, MM_ANONPAGES may be much bigger than anon LRU. > > MM_ANONPAGES should not be inc'ed unless a new page is allocated and > installed, right? I just realized I mixed MM_ANONPAGES up with the global anon pages counter. Take back my comment. Sorry for the confusion. > > > > > Cc: Andrew Morton > > Cc: Zi Yan > > Cc: linux-mm@kvack.org > > Cc: linux-kernel@vger.kernel.org > > Signed-off-by: Anshuman Khandual > > --- > > Should it update MM_SHMEM_PAGES instead ? Applies on latest mainline. > > > > mm/huge_memory.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > index 63ed6b25deaa..262703304807 100644 > > --- a/mm/huge_memory.c > > +++ b/mm/huge_memory.c > > @@ -706,6 +706,7 @@ static void set_huge_zero_page(pgtable_t pgtable, struct mm_struct *mm, > > if (pgtable) > > pgtable_trans_huge_deposit(mm, pmd, pgtable); > > set_pmd_at(mm, haddr, pmd, entry); > > + add_mm_counter(mm, MM_ANONPAGES, HPAGE_PMD_NR); > > mm_inc_nr_ptes(mm); > > } > > > > -- > > 2.20.1 > > > > 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=-12.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 69805C433ED for ; Thu, 13 May 2021 16:59:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1324D6143C for ; Thu, 13 May 2021 16:59:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1324D6143C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A61EF6B006E; Thu, 13 May 2021 12:59:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C1426B0070; Thu, 13 May 2021 12:59:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83B6D6B0071; Thu, 13 May 2021 12:59:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0029.hostedemail.com [216.40.44.29]) by kanga.kvack.org (Postfix) with ESMTP id 52E086B006E for ; Thu, 13 May 2021 12:59:48 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id EA9598789 for ; Thu, 13 May 2021 16:59:47 +0000 (UTC) X-FDA: 78136819614.03.7B88D62 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf18.hostedemail.com (Postfix) with ESMTP id C1D5C2000252 for ; Thu, 13 May 2021 16:59:46 +0000 (UTC) Received: by mail-ej1-f43.google.com with SMTP id l1so4818250ejb.6 for ; Thu, 13 May 2021 09:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qlfKotu9sca7LHhOUQlejV4TMBT38h8R33rjxE+jdW8=; b=Zqr3iG+q0GJOewBqwZhZyyP9OMzSabGqlImo0bNoJVzWNtvVPzvEP4Eq5tNFu3YVCy GhfQsgXXr2hD2WSkbDSAM6y1eOseCYhVMPBgMO6rs9OZST5ITs6bRMSE2ooZzbHO6hcg yTWC/G33pE9f1kH7cxRgHRs0MeGiTmsciBFOhYqqSWjafMzr93SpShiV7tgEBi6bL43d aAbnvQ1uzcaqBNMOwwBveKW+jJn++qrSPPEhNd5fnyk+xjQDEzsQjFtXsazEimGRydJ9 FvAkDicbe8lru1funJlzYAkUsOtq7+jAUIwGBaspsNp6/Zmjr3J21Sv4wxQVxD+rD3To qhOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qlfKotu9sca7LHhOUQlejV4TMBT38h8R33rjxE+jdW8=; b=denuMLm0Gc3rmWbs5o2i/SgnmHrGnauaoPse1UthQ3KdHktsSyjcYkPkk3CzQUAuiM vffbxqwieWbSSIgXK+O8oE2iMHX2OSUUx4Szl4P/E8lOtZrZhzQ+x6AMAeDuE6p+b8qM NAE4EVzICgmdUcyhGtDWWI/bjowC4O/MW70BJTeOKlPYu9Fg9HDWX42R/zFEElq9rwGj pWK0XQRQfruy9OTYUhEXBXpX/eJjPjRu+jtxKumZ+sciyw42ZjJWNK0cEG3o3noRUnKY /GiovgUZu6t4+RYreHKl0BskADefde/InTnpXW49MI8rHExaoqBLLsvq+Sn2B7R64X2n p7Kg== X-Gm-Message-State: AOAM532p7J6IYx3mreuXLIG1Ds6yikscicQNQZuq9NBI55zBC1IQjG3T +IZmO10iOaFTzDVKwcTnC8rUQKdKFgCSSHwZo+A= X-Google-Smtp-Source: ABdhPJwTw/EhzpOLvZKoM7wzshi7JIeiZlRD0pSH09UR1VbFoI380Mgzy6S0IYW9rB5Yrs2Pq87gtWFtP0E92gIExkE= X-Received: by 2002:a17:906:b7d6:: with SMTP id fy22mr1236673ejb.383.1620925186436; Thu, 13 May 2021 09:59:46 -0700 (PDT) MIME-Version: 1.0 References: <1620890438-9127-1-git-send-email-anshuman.khandual@arm.com> In-Reply-To: From: Yang Shi Date: Thu, 13 May 2021 09:59:34 -0700 Message-ID: Subject: Re: [RFC] mm/thp: Update mm's MM_ANONPAGES stat in set_huge_zero_page() To: Anshuman Khandual Cc: Linux MM , Andrew Morton , Zi Yan , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: C1D5C2000252 Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=Zqr3iG+q; spf=pass (imf18.hostedemail.com: domain of shy828301@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam04 X-Stat-Signature: woajmxmbc1fuhaqgi9n9kr3tmfxd31ib X-HE-Tag: 1620925186-58859 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 Thu, May 13, 2021 at 9:50 AM Yang Shi wrote: > > On Thu, May 13, 2021 at 12:20 AM Anshuman Khandual > wrote: > > > > Although the zero huge page is being shared across various processes, each > > mapping needs to update its mm's MM_ANONPAGES stat by HPAGE_PMD_NR in order > > to be consistent. This just updates the stats in set_huge_zero_page() after > > the mapping gets created. > > I don't get why MM_ANONPAGES needs to be inc'ed when huge zero page is > installed. This may cause inconsistency between some counters, for > example, MM_ANONPAGES may be much bigger than anon LRU. > > MM_ANONPAGES should not be inc'ed unless a new page is allocated and > installed, right? I just realized I mixed MM_ANONPAGES up with the global anon pages counter. Take back my comment. Sorry for the confusion. > > > > > Cc: Andrew Morton > > Cc: Zi Yan > > Cc: linux-mm@kvack.org > > Cc: linux-kernel@vger.kernel.org > > Signed-off-by: Anshuman Khandual > > --- > > Should it update MM_SHMEM_PAGES instead ? Applies on latest mainline. > > > > mm/huge_memory.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > index 63ed6b25deaa..262703304807 100644 > > --- a/mm/huge_memory.c > > +++ b/mm/huge_memory.c > > @@ -706,6 +706,7 @@ static void set_huge_zero_page(pgtable_t pgtable, struct mm_struct *mm, > > if (pgtable) > > pgtable_trans_huge_deposit(mm, pmd, pgtable); > > set_pmd_at(mm, haddr, pmd, entry); > > + add_mm_counter(mm, MM_ANONPAGES, HPAGE_PMD_NR); > > mm_inc_nr_ptes(mm); > > } > > > > -- > > 2.20.1 > > > >