linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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



  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