linux-kernel - Re: [PATCH v4 1/2] mm: count the number of anonymous THPs per size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3e8add35-e26b-443b-8a04-1078f4bc78f6@redhat.com>
Date: Mon, 26 Aug 2024 08:35:07 +0200
From: David Hildenbrand <david@...hat.com>
To: Barry Song <21cnbao@...il.com>, akpm@...ux-foundation.org,
 linux-mm@...ck.org
Cc: baolin.wang@...ux.alibaba.com, chrisl@...nel.org, hanchuanhua@...o.com,
 ioworker0@...il.com, kaleshsingh@...gle.com, kasong@...cent.com,
 linux-kernel@...r.kernel.org, ryan.roberts@....com, usamaarif642@...il.com,
 v-songbaohua@...o.com, yuanshuai@...o.com, ziy@...dia.com
Subject: Re: [PATCH v4 1/2] mm: count the number of anonymous THPs per size

On 24.08.24 03:04, Barry Song wrote:
> From: Barry Song <v-songbaohua@...o.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@...o.com>
> Acked-by: David Hildenbrand <david@...hat.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