From: Randy Dunlap <rdunlap@infradead.org>
To: Nico Pache <npache@redhat.com>,
linux-mm@kvack.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Cc: akpm@linux-foundation.org, corbet@lwn.net, shuah@kernel.org,
david@redhat.com, baohua@kernel.org,
baolin.wang@linux.alibaba.com, ryan.roberts@arm.com,
willy@infradead.org, peterx@redhat.com, ioworker0@gmail.com,
ziy@nvidia.com, wangkefeng.wang@huawei.com, dev.jain@arm.com,
mhocko@suse.com, rientjes@google.com, hannes@cmpxchg.org,
zokeefe@google.com, surenb@google.com, jglisse@google.com,
cl@gentwo.org, jack@suse.cz, dave.hansen@linux.intel.com,
will@kernel.org, tiwai@suse.de, catalin.marinas@arm.com,
anshuman.khandual@arm.com, raquini@redhat.com,
aarcange@redhat.com, kirill.shutemov@linux.intel.com,
yang@os.amperecomputing.com, thomas.hellstrom@linux.intel.com,
vishal.moola@gmail.com, sunnanyong@huawei.com,
usamaarif642@gmail.com, mathieu.desnoyers@efficios.com,
mhiramat@kernel.org, rostedt@goodmis.org
Subject: Re: [PATCH v3 2/4] mm: document (m)THP defer usage
Date: Mon, 14 Apr 2025 15:33:38 -0700 [thread overview]
Message-ID: <8fbdd651-c965-4fa7-a715-e01092f5de7b@infradead.org> (raw)
In-Reply-To: <20250414222456.43212-3-npache@redhat.com>
On 4/14/25 3:24 PM, Nico Pache wrote:
> The new defer option for (m)THPs allows for a more conservative
> approach to (m)THPs. Document its usage in the transhuge admin-guide.
>
> Signed-off-by: Nico Pache <npache@redhat.com>
> ---
> Documentation/admin-guide/mm/transhuge.rst | 31 ++++++++++++++++------
> 1 file changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst
> index f0d4e78cedaa..d3f072bdd932 100644
> --- a/Documentation/admin-guide/mm/transhuge.rst
> +++ b/Documentation/admin-guide/mm/transhuge.rst
> @@ -88,8 +88,9 @@ In certain cases when hugepages are enabled system wide, application
> may end up allocating more memory resources. An application may mmap a
> large region but only touch 1 byte of it, in that case a 2M page might
> be allocated instead of a 4k page for no good. This is why it's
> -possible to disable hugepages system-wide and to only have them inside
> -MADV_HUGEPAGE madvise regions.
> +possible to disable hugepages system-wide, only have them inside
> +MADV_HUGEPAGE madvise regions, or defer them away from the page fault
> +handler to khugepaged.
>
> Embedded systems should enable hugepages only inside madvise regions
> to eliminate any risk of wasting any precious byte of memory and to
> @@ -99,6 +100,15 @@ Applications that gets a lot of benefit from hugepages and that don't
> risk to lose memory by using hugepages, should use
> madvise(MADV_HUGEPAGE) on their critical mmapped regions.
>
> +Applications that would like to benefit from THPs but would still like a
> +more memory conservative approach can choose 'defer'. This avoids
> +inserting THPs at the page fault handler unless they are MADV_HUGEPAGE.
> +Khugepaged will then scan the mappings for potential collapses into (m)THP
> +pages. Admins using this the 'defer' setting should consider
> +tweaking khugepaged/max_ptes_none. The current default of 511 may
> +aggressively collapse your PTEs into PMDs. Lower this value to conserve
> +more memory (ie. max_ptes_none=64).
i.e.,
> +
> .. _thp_sysfs:
>
> sysfs
> @@ -109,11 +119,14 @@ Global THP controls
>
> Transparent Hugepage Support for anonymous memory can be entirely disabled
> (mostly for debugging purposes) or only enabled inside MADV_HUGEPAGE
> -regions (to avoid the risk of consuming more memory resources) or enabled
> -system wide. This can be achieved per-supported-THP-size with one of::
> +regions (to avoid the risk of consuming more memory resources), defered to
deferred
> +khugepaged, or enabled system wide.
> +
> +This can be achieved per-supported-THP-size with one of::
>
> echo always >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
> echo madvise >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
> + echo defer >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
> echo never >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
>
> where <size> is the hugepage size being addressed, the available sizes
> @@ -136,6 +149,7 @@ The top-level setting (for use with "inherit") can be set by issuing
> one of the following commands::
>
> echo always >/sys/kernel/mm/transparent_hugepage/enabled
> + echo defer >/sys/kernel/mm/transparent_hugepage/enabled
> echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
> echo never >/sys/kernel/mm/transparent_hugepage/enabled
>
> @@ -281,7 +295,8 @@ of small pages into one large page::
> A higher value leads to use additional memory for programs.
> A lower value leads to gain less thp performance. Value of
> max_ptes_none can waste cpu time very little, you can
> -ignore it.
> +ignore it. Consider lowering this value when using
> +``transparent_hugepage=defer``
>
> ``max_ptes_swap`` specifies how many pages can be brought in from
> swap when collapsing a group of pages into a transparent huge page::
> @@ -306,14 +321,14 @@ Boot parameters
>
> You can change the sysfs boot time default for the top-level "enabled"
> control by passing the parameter ``transparent_hugepage=always`` or
> -``transparent_hugepage=madvise`` or ``transparent_hugepage=never`` to the
> -kernel command line.
> +``transparent_hugepage=madvise`` or ``transparent_hugepage=defer`` or
> +``transparent_hugepage=never`` to the kernel command line.
>
> Alternatively, each supported anonymous THP size can be controlled by
> passing ``thp_anon=<size>[KMG],<size>[KMG]:<state>;<size>[KMG]-<size>[KMG]:<state>``,
> where ``<size>`` is the THP size (must be a power of 2 of PAGE_SIZE and
> supported anonymous THP) and ``<state>`` is one of ``always``, ``madvise``,
> -``never`` or ``inherit``.
> +``defer``, ``never`` or ``inherit``.
>
> For example, the following will set 16K, 32K, 64K THP to ``always``,
> set 128K, 512K to ``inherit``, set 256K to ``madvise`` and 1M, 2M
--
~Randy
next prev parent reply other threads:[~2025-04-14 22:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-14 22:24 [PATCH v3 0/4] mm: introduce THP deferred setting Nico Pache
2025-04-14 22:24 ` [PATCH v3 1/4] mm: defer THP insertion to khugepaged Nico Pache
2025-04-14 22:24 ` [PATCH v3 2/4] mm: document (m)THP defer usage Nico Pache
2025-04-14 22:33 ` Randy Dunlap [this message]
2025-04-14 22:24 ` [PATCH v3 3/4] khugepaged: add defer option to mTHP options Nico Pache
2025-04-14 22:24 ` [PATCH v3 4/4] selftests: mm: add defer to thp setting parser Nico Pache
2025-04-15 0:37 ` [PATCH v3 0/4] mm: introduce THP deferred setting Andrew Morton
2025-04-15 0:50 ` Andrew Morton
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=8fbdd651-c965-4fa7-a715-e01092f5de7b@infradead.org \
--to=rdunlap@infradead.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=catalin.marinas@arm.com \
--cc=cl@gentwo.org \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=dev.jain@arm.com \
--cc=hannes@cmpxchg.org \
--cc=ioworker0@gmail.com \
--cc=jack@suse.cz \
--cc=jglisse@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=npache@redhat.com \
--cc=peterx@redhat.com \
--cc=raquini@redhat.com \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=ryan.roberts@arm.com \
--cc=shuah@kernel.org \
--cc=sunnanyong@huawei.com \
--cc=surenb@google.com \
--cc=thomas.hellstrom@linux.intel.com \
--cc=tiwai@suse.de \
--cc=usamaarif642@gmail.com \
--cc=vishal.moola@gmail.com \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=yang@os.amperecomputing.com \
--cc=ziy@nvidia.com \
--cc=zokeefe@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.