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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01F42C52D73 for ; Fri, 9 Aug 2024 08:13:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 195C66B0089; Fri, 9 Aug 2024 04:13:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 11E476B008A; Fri, 9 Aug 2024 04:13:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED9A76B008C; Fri, 9 Aug 2024 04:13:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C74316B0089 for ; Fri, 9 Aug 2024 04:13:52 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 53B94A51D9 for ; Fri, 9 Aug 2024 08:13:52 +0000 (UTC) X-FDA: 82431993504.14.2B22A9F Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf18.hostedemail.com (Postfix) with ESMTP id 765B01C000D for ; Fri, 9 Aug 2024 08:13:50 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723191164; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JTGxdDI2fwNEv/6gVXS4ySVFBdyCZzoU+loOuwpSs8Y=; b=oEsFUAyJL5GngA/93+Pu7qDuaWTQVH2Rvy1fqSsnkv/pscoEsDCcaZfzidgcijnultKe2G eVUhv/daj5AfHfVa7jqY4aRiLLhVs8jnqVSUl0H7FYuX+n6x6FUE8xj6N7tgffy9uFCfJo foCvnlSvznDRIA+nYDr7AiMm/0See4E= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723191164; a=rsa-sha256; cv=none; b=EZYcYiUK/f2Znk1+h9ahr8QwEJjCabnOqRFZH9X+mhWziblH709DUfpCAPudgSgvA1NWWa xFxX17/5sR64OeYcjvUgx19A9qbTn4wTvUDF8eBd2i0mVVLpCFvXPE3sPVR6jjiuPiulbo fXxPwfo9EWPORDYMI0w7yDW4733Siic= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com 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 6F84EFEC; Fri, 9 Aug 2024 01:14:15 -0700 (PDT) Received: from [10.57.95.64] (unknown [10.57.95.64]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ECCA03F6A8; Fri, 9 Aug 2024 01:13:47 -0700 (PDT) Message-ID: Date: Fri, 9 Aug 2024 09:13:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC 1/2] mm: collect the number of anon large folios Content-Language: en-GB To: Barry Song <21cnbao@gmail.com>, akpm@linux-foundation.org, linux-mm@kvack.org Cc: chrisl@kernel.org, david@redhat.com, kaleshsingh@google.com, kasong@tencent.com, linux-kernel@vger.kernel.org, ioworker0@gmail.com, baolin.wang@linux.alibaba.com, ziy@nvidia.com, hanchuanhua@oppo.com, Barry Song References: <20240808010457.228753-1-21cnbao@gmail.com> <20240808010457.228753-2-21cnbao@gmail.com> From: Ryan Roberts In-Reply-To: <20240808010457.228753-2-21cnbao@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: 781iaayzo3xbbttpbfr4fsus1rnc7989 X-Rspamd-Queue-Id: 765B01C000D X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1723191230-518965 X-HE-Meta: U2FsdGVkX1+NGbq6pLRYxVuVBAvLrbi6uYwRXDdwMKyCUH/GDmoxDcKcDLQZAmKPud6KNo8pYLc2Ittk7Gb1tGT6/ibMGy1giLy3cnVTJV/k7PcT9oq5oejOucg9V5TTFdzt9EMAOr32Dv+pnrTRb0jMwW26600WGWCCTTx3uXSaKcVjniE4Ku7/AHoywbCkdR7Acnv2c/aOBUZeKApVrR0DbYPHirULyXvXy3wS7Ibs5Ox34631+nDyaxkd3fYP3Je5Md4niwhcPtqmHsVJm+CG/Ah4flrVwaVREVVqstZjV+0wtiH9mSS7wYt2rIipvbNZoZDwsLSArCEBBsV/bKKkT33UxKGET//FIcytQwvoCRGFAt4EA1VesCOTcGQFy5oKUEX/ystsbklhAcCBiXheZACoiSJb+8Cc9LnZFmpsHZP4tRDl0m4rJD89DW0yixEWdbOOe3FJH6EJmzVFuk8REGQg9w/xggruu7KJ2QMD8vqbYWXK6aMPpTQi0JUvcUt1UCqe2Vqv37pNii5LiH8tyqrlxY6WgrUDPNa6RsLAQoLXmIYu6jmOp5W0fqbM+O3h9Lwm82J8ufPZ3GjMGvgPCEFTw2Wt+pLCy8MJVT40TtA53Wy0EUwn3PdX5b2pGXf/bdZ4zT7cYjkP+fzyyNJmN1UH/Ju7/nU5tdbi3vg/D5OD5DXTbtGrWy6e2Q9BzK0r5TvW8zxV6Er9D6dI3LigpGVgc/WbqLEgsiLeoMZD7MuOg0m6Tf0NjSdlVkKroXesfirAnpyKIjjDW0SUY/qV730bTeAtCUp8PSak3ErNUlqCVOtyVqoRgZ9AdZVoqpW5Wk+rPrFQEXrfsR9mmoU42vZqk0A64R+9JdtCylbui3VqDajdexmrq1S82ZgrCtZ3bL+5YyJqnXYpyCDQ8rPErFRiQTv98Xx/mvCUBbfoH5iuwz87QCV79fPCQ5zjlM6pnf/Z4e/szRedEYf 9aMPaWmv khewOummXThgyRwUiaWKzCJB1EjmzCFqo69sPjPtoSpjLBKFxMhSO3wo5TFS+joB6r76vL5XGQzhFMDdeBqBU6bW3T748LmPatHcEnIeVtoeSEpF6K0br/hYQq7SYxC7LOJ+elAbpG0apAtYHmpveECnJSUHkPDBw6yMov5DwRdIPOG4J04RDLppSIvqv9R+VnM2MpknBLyEAbDQ= 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: List-Subscribe: List-Unsubscribe: On 08/08/2024 02:04, Barry Song wrote: > From: Barry Song > > When a new anonymous mTHP is added to the rmap, we increase the count. > We reduce the count whenever an mTHP is completely unmapped. > > Signed-off-by: Barry Song > --- > Documentation/admin-guide/mm/transhuge.rst | 5 +++++ > include/linux/huge_mm.h | 15 +++++++++++++-- > mm/huge_memory.c | 2 ++ > mm/rmap.c | 3 +++ > 4 files changed, 23 insertions(+), 2 deletions(-) > > diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst > index 058485daf186..715f181543f6 100644 > --- a/Documentation/admin-guide/mm/transhuge.rst > +++ b/Documentation/admin-guide/mm/transhuge.rst > @@ -527,6 +527,11 @@ split_deferred > it would free up some memory. Pages on split queue are going to > be split under memory pressure, if splitting is possible. > > +anon_num > + the number of anon huge pages we have in the whole system. > + These huge pages could be still entirely mapped and have partially > + unmapped and unused subpages. nit: "entirely mapped and have partially unmapped and unused subpages" -> "entirely mapped or have partially unmapped/unused subpages" > + > As the system ages, allocating huge pages may be expensive as the > system uses memory compaction to copy data around memory to free a > huge page for use. There are some counters in ``/proc/vmstat`` to help > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > index e25d9ebfdf89..294c348fe3cc 100644 > --- a/include/linux/huge_mm.h > +++ b/include/linux/huge_mm.h > @@ -281,6 +281,7 @@ enum mthp_stat_item { > MTHP_STAT_SPLIT, > MTHP_STAT_SPLIT_FAILED, > MTHP_STAT_SPLIT_DEFERRED, > + MTHP_STAT_NR_ANON, > __MTHP_STAT_COUNT > }; > > @@ -291,14 +292,24 @@ struct mthp_stat { > #ifdef CONFIG_SYSFS > DECLARE_PER_CPU(struct mthp_stat, mthp_stats); > > -static inline void count_mthp_stat(int order, enum mthp_stat_item item) > +static inline void mod_mthp_stat(int order, enum mthp_stat_item item, int delta) > { > if (order <= 0 || order > PMD_ORDER) > return; > > - this_cpu_inc(mthp_stats.stats[order][item]); > + this_cpu_add(mthp_stats.stats[order][item], delta); > +} > + > +static inline void count_mthp_stat(int order, enum mthp_stat_item item) > +{ > + mod_mthp_stat(order, item, 1); > } > + > #else > +static inline void mod_mthp_stat(int order, enum mthp_stat_item item, int delta) > +{ > +} > + > static inline void count_mthp_stat(int order, enum mthp_stat_item item) > { > } > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 697fcf89f975..b6bc2a3791e3 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -578,6 +578,7 @@ DEFINE_MTHP_STAT_ATTR(shmem_fallback_charge, MTHP_STAT_SHMEM_FALLBACK_CHARGE); > DEFINE_MTHP_STAT_ATTR(split, MTHP_STAT_SPLIT); > DEFINE_MTHP_STAT_ATTR(split_failed, MTHP_STAT_SPLIT_FAILED); > DEFINE_MTHP_STAT_ATTR(split_deferred, MTHP_STAT_SPLIT_DEFERRED); > +DEFINE_MTHP_STAT_ATTR(anon_num, MTHP_STAT_NR_ANON); > > static struct attribute *stats_attrs[] = { > &anon_fault_alloc_attr.attr, > @@ -591,6 +592,7 @@ static struct attribute *stats_attrs[] = { > &split_attr.attr, > &split_failed_attr.attr, > &split_deferred_attr.attr, > + &anon_num_attr.attr, > NULL, > }; > > diff --git a/mm/rmap.c b/mm/rmap.c > index 901950200957..2b722f26224c 100644 > --- a/mm/rmap.c > +++ b/mm/rmap.c > @@ -1467,6 +1467,7 @@ void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma, > } > > __folio_mod_stat(folio, nr, nr_pmdmapped); > + mod_mthp_stat(folio_order(folio), MTHP_STAT_NR_ANON, 1); > } > > static __always_inline void __folio_add_file_rmap(struct folio *folio, > @@ -1582,6 +1583,8 @@ static __always_inline void __folio_remove_rmap(struct folio *folio, > list_empty(&folio->_deferred_list)) > deferred_split_folio(folio); > __folio_mod_stat(folio, -nr, -nr_pmdmapped); > + if (folio_test_anon(folio) && !atomic_read(mapped)) Agree that atomic_read() is dodgy here. Not sure I fully understand why David prefers to do the unaccounting at free-time though? It feels unbalanced to me to increment when first mapped but decrement when freed. Surely its safer to either use alloc/free or use first map/last map? If using alloc/free isn't there a THP constructor/destructor that prepares the deferred list? (My memory may be failing me). Could we use that? > + mod_mthp_stat(folio_order(folio), MTHP_STAT_NR_ANON, -1); > > /* > * It would be tidy to reset folio_test_anon mapping when fully