From: David Hildenbrand <david@redhat.com>
To: Barry Song <21cnbao@gmail.com>,
akpm@linux-foundation.org, linux-mm@kvack.org
Cc: baolin.wang@linux.alibaba.com, chrisl@kernel.org,
hanchuanhua@oppo.com, ioworker0@gmail.com,
kaleshsingh@google.com, kasong@tencent.com,
linux-kernel@vger.kernel.org, ryan.roberts@arm.com,
usamaarif642@gmail.com, v-songbaohua@oppo.com,
yuanshuai@oppo.com, ziy@nvidia.com
Subject: Re: [PATCH v4 1/2] mm: count the number of anonymous THPs per size
Date: Mon, 26 Aug 2024 08:35:07 +0200 [thread overview]
Message-ID: <3e8add35-e26b-443b-8a04-1078f4bc78f6@redhat.com> (raw)
In-Reply-To: <20240824010441.21308-2-21cnbao@gmail.com>
On 24.08.24 03:04, Barry Song wrote:
> From: Barry Song <v-songbaohua@oppo.com>
>
> Let's track for each anonymous THP size, how many of them are currently
> allocated. We'll track the complete lifespan of an anon THP, starting
> when it becomes an anon THP ("large anon folio") (->mapping gets set),
> until it gets freed (->mapping gets cleared).
>
> Introduce a new "nr_anon" counter per THP size and adjust the
> corresponding counter in the following cases:
> * We allocate a new THP and call folio_add_new_anon_rmap() to map
> it the first time and turn it into an anon THP.
> * We split an anon THP into multiple smaller ones.
> * We migrate an anon THP, when we prepare the destination.
> * We free an anon THP back to the buddy.
>
> Note that AnonPages in /proc/meminfo currently tracks the total number
> of *mapped* anonymous *pages*, and therefore has slightly different
> semantics. In the future, we might also want to track "nr_anon_mapped"
> for each THP size, which might be helpful when comparing it to the
> number of allocated anon THPs (long-term pinning, stuck in swapcache,
> memory leaks, ...).
>
> Further note that for now, we only track anon THPs after they got their
> ->mapping set, for example via folio_add_new_anon_rmap(). If we would
> allocate some in the swapcache, they will only show up in the statistics
> for now after they have been mapped to user space the first time, where
> we call folio_add_new_anon_rmap().
>
> Signed-off-by: Barry Song <v-songbaohua@oppo.com>
> Acked-by: David Hildenbrand <david@redhat.com>
> ---
> Documentation/admin-guide/mm/transhuge.rst | 5 +++++
> include/linux/huge_mm.h | 15 +++++++++++++--
> mm/huge_memory.c | 13 ++++++++++---
> mm/migrate.c | 4 ++++
> mm/page_alloc.c | 5 ++++-
> mm/rmap.c | 1 +
> 6 files changed, 37 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst
> index 79435c537e21..b78f2148b242 100644
> --- a/Documentation/admin-guide/mm/transhuge.rst
> +++ b/Documentation/admin-guide/mm/transhuge.rst
> @@ -551,6 +551,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.
>
In light of documentation of patch #2, small nits:
> +nr_anon
> + the number of transparent anon huge pages we have in the whole system.
s/transparent anon huge pages/anonymous THP/
> + These huge pages could be entirely mapped or have partially
s/huge pages/THPs/
s/could be/might be currently/
Maybe Andrew can just fix it up if there are no other comments.
Thanks!
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-08-26 6:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-24 1:04 [PATCH v4 0/2] " Barry Song
2024-08-24 1:04 ` [PATCH v4 1/2] " Barry Song
2024-08-26 6:35 ` David Hildenbrand [this message]
2024-09-09 19:56 ` chunpeng lee
2024-08-24 1:04 ` [PATCH v4 2/2] mm: count the number of partially mapped " Barry Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3e8add35-e26b-443b-8a04-1078f4bc78f6@redhat.com \
--to=david@redhat.com \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=chrisl@kernel.org \
--cc=hanchuanhua@oppo.com \
--cc=ioworker0@gmail.com \
--cc=kaleshsingh@google.com \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryan.roberts@arm.com \
--cc=usamaarif642@gmail.com \
--cc=v-songbaohua@oppo.com \
--cc=yuanshuai@oppo.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox