From: Andrew Morton <akpm@linux-foundation.org>
To: Michal Hocko <mhocko@suse.com>
Cc: Dmitry Ilvokhin <d@ilvokhin.com>,
David Hildenbrand <david@redhat.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Hugh Dickins <hughd@google.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Kiryl Shutsemau <kas@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com
Subject: Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice
Date: Sat, 25 Oct 2025 21:29:08 -0700 [thread overview]
Message-ID: <20251025212908.8f85fad99c4b78e528a7e324@linux-foundation.org> (raw)
In-Reply-To: <aPtpt4hYMuJnwnOO@tiehlicka>
On Fri, 24 Oct 2025 13:57:43 +0200 Michal Hocko <mhocko@suse.com> wrote:
> > In short, primary benefit is mostly operational: it provides a way to
> > codify preferred policy in the kernel configuration, which is versioned,
> > reviewed, and tested as part of the kernel build process, rather than
> > depending on potentially variable boot parameters.
>
> Please expand the changelog with this explanation. Thanks!
I pasted it as below.
> > I hope possible operational benefits outweigh downsides from increasing
> > the config space. Please, let me know if this argument sounds
> > reasonable to you, I'll rephrase commit message for v2 to include this
> > reasoning.
>
> Yes, this is exactly what I was looking for. Thank you.
Yep, super helpful.
From: Dmitry Ilvokhin <d@ilvokhin.com>
Subject: mm: shmem/tmpfs hugepage defaults config choice
Date: Thu, 23 Oct 2025 18:12:02 +0000
Allow to override defaults for shmem and tmpfs at config time. This is
consistent with how transparent hugepages can be configured.
Same results can be achieved with the existing
'transparent_hugepage_shmem' and 'transparent_hugepage_tmpfs' settings in
the kernel command line, but it is more convenient to define basic
settings at config time instead of changing kernel command line later.
Defaults for shmem and tmpfs were not changed. They are remained the same
as before: 'never' for both cases. Options 'deny' and 'force' are omitted
intentionally since these are special values and supposed to be used for
emergencies or testing and are not expected to be permanent ones.
Primary motivation for adding config option is to enable policy
enforcement at build time. In large-scale production environments
(Meta's for example), the kernel configuration is often maintained
centrally close to the kernel code itself and owned by the kernel
engineers, while boot parameters are managed independently (e.g. by
provisioning systems). In such setups, the kernel build defines the
supported and expected behavior in a single place, but there is no
reliable or uniform control over the kernel command line options.
A build-time default allows kernel integrators to enforce a predictable
hugepage policy for shmem/tmpfs on a base layer, ensuring reproducible
behavior and avoiding configuration drift caused by possible boot-time
differences.
In short, primary benefit is mostly operational: it provides a way to
codify preferred policy in the kernel configuration, which is
versioned, reviewed, and tested as part of the kernel build process,
rather than depending on potentially variable boot parameters.
Link: https://lkml.kernel.org/r/aPpv8sAa2sYgNu3L@shell.ilvokhin.com
Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Liam Howlett <liam.howlett@oracle.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/Kconfig | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++
mm/shmem.c | 33 +++++++++++++++++-
2 files changed, 122 insertions(+), 2 deletions(-)
--- a/mm/Kconfig~mm-shmem-tmpfs-hugepage-defaults-config-choice
+++ a/mm/Kconfig
@@ -853,6 +853,97 @@ choice
enabled at runtime via sysfs.
endchoice
+choice
+ prompt "Shmem hugepage allocation defaults"
+ depends on TRANSPARENT_HUGEPAGE
+ default TRANSPARENT_HUGEPAGE_SHMEM_HUGE_NEVER
+ help
+ Selects the hugepage allocation policy defaults for
+ the internal shmem mount.
+
+ The selection made here can be overridden by using the kernel
+ command line 'transparent_hugepage_shmem=' option.
+
+ config TRANSPARENT_HUGEPAGE_SHMEM_HUGE_NEVER
+ bool "never"
+ help
+ Disable hugepage allocation for shmem mount by default. It can
+ still be enabled with the kernel command line
+ 'transparent_hugepage_shmem=' option or at runtime via sysfs
+ knob. Note that madvise(MADV_COLLAPSE) can still cause
+ transparent huge pages to be obtained even if this mode is
+ specified.
+
+ config TRANSPARENT_HUGEPAGE_SHMEM_HUGE_ALWAYS
+ bool "always"
+ help
+ Always attempt to allocate hugepage for shmem mount, can
+ increase the memory footprint of applications without a
+ guaranteed benefit but it will work automatically for all
+ applications.
+
+ config TRANSPARENT_HUGEPAGE_SHMEM_HUGE_WITHIN_SIZE
+ bool "within_size"
+ help
+ Enable hugepage allocation for shmem mount if the allocation
+ will be fully within the i_size. This configuration also takes
+ into account any madvise(MADV_HUGEPAGE) hints that may be
+ provided by the applications.
+
+ config TRANSPARENT_HUGEPAGE_SHMEM_HUGE_ADVISE
+ bool "advise"
+ help
+ Enable hugepage allocation for the shmem mount exclusively when
+ applications supply the madvise(MADV_HUGEPAGE) hint.
+ This ensures that hugepages are used only in response to explicit
+ requests from applications.
+endchoice
+
+choice
+ prompt "Tmpfs hugepage allocation defaults"
+ depends on TRANSPARENT_HUGEPAGE
+ default TRANSPARENT_HUGEPAGE_TMPFS_HUGE_NEVER
+ help
+ Selects the hugepage allocation policy defaults for
+ the tmpfs mount.
+
+ The selection made here can be overridden by using the kernel
+ command line 'transparent_hugepage_tmpfs=' option.
+
+ config TRANSPARENT_HUGEPAGE_TMPFS_HUGE_NEVER
+ bool "never"
+ help
+ Disable hugepage allocation for tmpfs mount by default. It can
+ still be enabled with the kernel command line
+ 'transparent_hugepage_tmpfs=' option. Note that
+ madvise(MADV_COLLAPSE) can still cause transparent huge pages
+ to be obtained even if this mode is specified.
+
+ config TRANSPARENT_HUGEPAGE_TMPFS_HUGE_ALWAYS
+ bool "always"
+ help
+ Always attempt to allocate hugepage for tmpfs mount, can
+ increase the memory footprint of applications without a
+ guaranteed benefit but it will work automatically for all
+ applications.
+
+ config TRANSPARENT_HUGEPAGE_TMPFS_HUGE_WITHIN_SIZE
+ bool "within_size"
+ help
+ Enable hugepage allocation for tmpfs mount if the allocation
+ will be fully within the i_size. This configuration also takes
+ into account any madvise(MADV_HUGEPAGE) hints that may be
+ provided by the applications.
+
+ config TRANSPARENT_HUGEPAGE_TMPFS_HUGE_ADVISE
+ bool "advise"
+ help
+ Enable hugepage allocation for the tmpfs mount exclusively when
+ applications supply the madvise(MADV_HUGEPAGE) hint.
+ This ensures that hugepages are used only in response to explicit
+ requests from applications.
+endchoice
+
config THP_SWAP
def_bool y
depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP && SWAP && 64BIT
--- a/mm/shmem.c~mm-shmem-tmpfs-hugepage-defaults-config-choice
+++ a/mm/shmem.c
@@ -570,8 +570,37 @@ static int shmem_confirm_swap(struct add
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
/* ifdef here to avoid bloating shmem.o when not necessary */
-static int shmem_huge __read_mostly = SHMEM_HUGE_NEVER;
-static int tmpfs_huge __read_mostly = SHMEM_HUGE_NEVER;
+#if defined(CONFIG_TRANSPARENT_HUGEPAGE_SHMEM_HUGE_NEVER)
+#define SHMEM_HUGE_DEFAULT SHMEM_HUGE_NEVER
+#elif defined(CONFIG_TRANSPARENT_HUGEPAGE_SHMEM_HUGE_ALWAYS)
+#define SHMEM_HUGE_DEFAULT SHMEM_HUGE_ALWAYS
+#elif defined(CONFIG_TRANSPARENT_HUGEPAGE_SHMEM_HUGE_WITHIN_SIZE)
+#define SHMEM_HUGE_DEFAULT SHMEM_HUGE_WITHIN_SIZE
+#elif defined(CONFIG_TRANSPARENT_HUGEPAGE_SHMEM_HUGE_ADVISE)
+#define SHMEM_HUGE_DEFAULT SHMEM_HUGE_ADVISE
+#else
+#define SHMEM_HUGE_DEFAULT SHMEM_HUGE_NEVER
+#endif
+
+static int shmem_huge __read_mostly = SHMEM_HUGE_DEFAULT;
+
+#undef SHMEM_HUGE_DEFAULT
+
+#if defined(CONFIG_TRANSPARENT_HUGEPAGE_TMPFS_HUGE_NEVER)
+#define TMPFS_HUGE_DEFAULT SHMEM_HUGE_NEVER
+#elif defined(CONFIG_TRANSPARENT_HUGEPAGE_TMPFS_HUGE_ALWAYS)
+#define TMPFS_HUGE_DEFAULT SHMEM_HUGE_ALWAYS
+#elif defined(CONFIG_TRANSPARENT_HUGEPAGE_TMPFS_HUGE_WITHIN_SIZE)
+#define TMPFS_HUGE_DEFAULT SHMEM_HUGE_WITHIN_SIZE
+#elif defined(CONFIG_TRANSPARENT_HUGEPAGE_TMPFS_HUGE_ADVISE)
+#define TMPFS_HUGE_DEFAULT SHMEM_HUGE_ADVISE
+#else
+#define TMPFS_HUGE_DEFAULT SHMEM_HUGE_NEVER
+#endif
+
+static int tmpfs_huge __read_mostly = TMPFS_HUGE_DEFAULT;
+
+#undef TMPFS_HUGE_DEFAULT
static unsigned int shmem_get_orders_within_size(struct inode *inode,
unsigned long within_size_orders, pgoff_t index,
_
next prev parent reply other threads:[~2025-10-26 4:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-23 18:12 Dmitry Ilvokhin
2025-10-23 21:26 ` Shakeel Butt
2025-10-24 1:40 ` Baolin Wang
2025-10-24 7:38 ` Michal Hocko
2025-10-24 11:19 ` Dmitry Ilvokhin
2025-10-24 11:57 ` Michal Hocko
2025-10-26 4:29 ` Andrew Morton [this message]
2025-10-24 20:35 ` Matthew Wilcox
2025-10-27 16:23 ` Dmitry Ilvokhin
2025-10-27 16:26 ` David Hildenbrand
2025-10-26 12:12 ` Yafang Shao
2025-10-27 15:43 ` Dmitry Ilvokhin
2025-10-24 19:54 ` Lorenzo Stoakes
2025-10-24 20:27 ` Pedro Falcato
2025-10-27 15:00 ` Dmitry Ilvokhin
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=20251025212908.8f85fad99c4b78e528a7e324@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=Liam.Howlett@oracle.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=d@ilvokhin.com \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=kas@kernel.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/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