From: Ryan Roberts <ryan.roberts@arm.com>
To: Barry Song <21cnbao@gmail.com>,
akpm@linux-foundation.org, linux-mm@kvack.org
Cc: cerasuolodomenico@gmail.com, chrisl@kernel.org, david@redhat.com,
kasong@tencent.com, linux-kernel@vger.kernel.org,
peterx@redhat.com, surenb@google.com, v-songbaohua@oppo.com,
willy@infradead.org, yosryahmed@google.com, yuzhao@google.com,
corbet@lwn.net
Subject: Re: [PATCH v5 3/4] mm: add docs for per-order mTHP counters and transhuge_page ABI
Date: Fri, 12 Apr 2024 11:19:56 +0100 [thread overview]
Message-ID: <b1f417fb-1f8b-4349-a6bc-97694b92587f@arm.com> (raw)
In-Reply-To: <20240412073740.294272-4-21cnbao@gmail.com>
On 12/04/2024 08:37, Barry Song wrote:
> From: Barry Song <v-songbaohua@oppo.com>
>
> This patch includes documentation for mTHP counters and an ABI file
> for sys-kernel-mm-transparent-hugepage, which appears to have been
> missing for some time.
>
> Signed-off-by: Barry Song <v-songbaohua@oppo.com>
> Cc: Chris Li <chrisl@kernel.org>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Domenico Cerasuolo <cerasuolodomenico@gmail.com>
> Cc: Kairui Song <kasong@tencent.com>
> Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
> Cc: Peter Xu <peterx@redhat.com>
> Cc: Ryan Roberts <ryan.roberts@arm.com>
> Cc: Suren Baghdasaryan <surenb@google.com>
> Cc: Yosry Ahmed <yosryahmed@google.com>
> Cc: Yu Zhao <yuzhao@google.com>
> Cc: Jonathan Corbet <corbet@lwn.net>
A few nits, but regardless:
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
> ---
> .../sys-kernel-mm-transparent-hugepage | 17 +++++++++++
> Documentation/admin-guide/mm/transhuge.rst | 28 +++++++++++++++++++
> 2 files changed, 45 insertions(+)
> create mode 100644 Documentation/ABI/testing/sys-kernel-mm-transparent-hugepage
>
> diff --git a/Documentation/ABI/testing/sys-kernel-mm-transparent-hugepage b/Documentation/ABI/testing/sys-kernel-mm-transparent-hugepage
> new file mode 100644
> index 000000000000..80dde0fd576c
> --- /dev/null
> +++ b/Documentation/ABI/testing/sys-kernel-mm-transparent-hugepage
> @@ -0,0 +1,17 @@
> +What: /sys/kernel/mm/hugepages/
Err, transparent_hugepage, right? copy/paste error?
> +Date: April 2024
> +Contact: Barry Song <baohua@kernel.org>
Looks like a bunch of mm sysfs interfaces use:
Contact: Linux memory management mailing list <linux-mm@kvack.org>
I'll leave that up to you!
> +Description:
> + /sys/kernel/mm/transparent_hugepage/ contains a number of files and
> + subdirectories,
> + - defrag
> + - enabled
> + - hpage_pmd_size
> + - khugepaged
> + - shmem_enabled
> + - use_zero_page
> + - subdirectories of the form hugepages-<size>kB, where <size>
> + is the page size of the hugepages supported by the kernel/CPU
> + combination.
> +
> + See Documentation/admin-guide/mm/transhuge.rst for details.> diff --git a/Documentation/admin-guide/mm/transhuge.rst
b/Documentation/admin-guide/mm/transhuge.rst
> index 04eb45a2f940..f436ff982f22 100644
> --- a/Documentation/admin-guide/mm/transhuge.rst
> +++ b/Documentation/admin-guide/mm/transhuge.rst
> @@ -447,6 +447,34 @@ thp_swpout_fallback
> Usually because failed to allocate some continuous swap space
> for the huge page.
>
> +In /sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/stats, There are
> +also individual counters for each huge page size, which can be utilized to
> +monitor the system's effectiveness in providing huge pages for usage. Each
> +counter has its own corresponding file.
> +
> +anon_fault_alloc
> + is incremented every time a huge page is successfully
> + allocated and charged to handle a page fault.
> +
> +anon_fault_fallback
> + is incremented if a page fault fails to allocate or charge
> + a huge page and instead falls back to using huge pages with
> + lower orders or small pages.
> +
> +anon_fault_fallback_charge
> + is incremented if a page fault fails to charge a huge page and
> + instead falls back to using huge pages with lower orders or
> + small pages even though the allocation was successful.
> +
> +anon_swpout
> + is incremented every time a huge page is swapout in one
nit: swapout -> "swapped out"? Although I see this is just a copy/paste of the
description of the existing counter...
> + piece without splitting.
> +
> +anon_swpout_fallback
> + is incremented if a huge page has to be split before swapout.
> + Usually because failed to allocate some continuous swap space
> + for the huge page.
> +
> 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
next prev parent reply other threads:[~2024-04-12 10:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-12 7:37 [PATCH v5 0/4] mm: add per-order mTHP alloc and swpout counters Barry Song
2024-04-12 7:37 ` [PATCH v5 1/4] mm: add per-order mTHP anon_fault_alloc and anon_fault_fallback counters Barry Song
2024-04-12 9:26 ` Ryan Roberts
2024-04-12 9:43 ` Barry Song
2024-04-12 9:56 ` Ryan Roberts
2024-04-12 10:17 ` Barry Song
2024-04-12 10:25 ` Ryan Roberts
2024-04-12 10:29 ` Barry Song
2024-04-12 10:38 ` Ryan Roberts
2024-04-12 10:53 ` Barry Song
2024-04-12 11:05 ` Ryan Roberts
2024-04-12 7:37 ` [PATCH v5 2/4] mm: add per-order mTHP anon_swpout and anon_swpout_fallback counters Barry Song
2024-04-12 9:43 ` Ryan Roberts
2024-04-12 7:37 ` [PATCH v5 3/4] mm: add docs for per-order mTHP counters and transhuge_page ABI Barry Song
2024-04-12 10:19 ` Ryan Roberts [this message]
2024-04-12 7:37 ` [PATCH v5 4/4] mm: correct the docs for thp_fault_alloc and thp_fault_fallback Barry Song
2024-04-12 10:21 ` Ryan Roberts
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=b1f417fb-1f8b-4349-a6bc-97694b92587f@arm.com \
--to=ryan.roberts@arm.com \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cerasuolodomenico@gmail.com \
--cc=chrisl@kernel.org \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
--cc=surenb@google.com \
--cc=v-songbaohua@oppo.com \
--cc=willy@infradead.org \
--cc=yosryahmed@google.com \
--cc=yuzhao@google.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