[PATCH] mm: shmem/tmpfs hugepage defaults config choice

[PATCH] mm: shmem/tmpfs hugepage defaults config choice

[Dmitry Ilvokhin]

Allow to override defaults for shemem 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.

Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
---
 mm/Kconfig | 91 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 mm/shmem.c | 33 ++++++++++++++++++--
 2 files changed, 122 insertions(+), 2 deletions(-)

diff --git a/mm/Kconfig b/mm/Kconfig
index e47321051d76..5ceea38edbe1 100644
--- a/mm/Kconfig
+++ b/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
diff --git a/mm/shmem.c b/mm/shmem.c
index eb8161136a7f..a411d7fb6e5a 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -570,8 +570,37 @@ static int shmem_confirm_swap(struct address_space *mapping, pgoff_t index,
 #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,
-- 
2.47.3

Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

[Shakeel Butt]

On Thu, Oct 23, 2025 at 06:12:02PM +0000, Dmitry Ilvokhin wrote:
> Allow to override defaults for shemem 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.
> 
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>

This looks good. I would recommend to also update
Documentation/admin-guide/mm/transhuge.rst with this build config
information.

Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

[Baolin Wang]

On 2025/10/24 02:12, Dmitry Ilvokhin wrote:
> Allow to override defaults for shemem 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.

Make sense to me.

> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>

With addressing Shakeel's comments:
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>

Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

[Michal Hocko]

On Thu 23-10-25 18:12:02, Dmitry Ilvokhin wrote:
> Allow to override defaults for shemem 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.

Being consistent is usually nice but you are not telling us _who_ is
going to benefit from this. Increasing the config space is not really
free. So please focus on Why do we need it rather than it is consistent
argument.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

[Dmitry Ilvokhin]

On Fri, Oct 24, 2025 at 09:38:53AM +0200, Michal Hocko wrote:
> On Thu 23-10-25 18:12:02, Dmitry Ilvokhin wrote:
> > Allow to override defaults for shemem 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.
> 
> Being consistent is usually nice but you are not telling us _who_ is
> going to benefit from this. Increasing the config space is not really
> free. So please focus on Why do we need it rather than it is consistent
> argument.

Thanks for the feedback, Michal, totally make sense to me, I should have
expand on this point in the initial commit message.

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.

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.

> 
> -- 
> Michal Hocko
> SUSE Labs

Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

[Michal Hocko]

On Fri 24-10-25 11:19:50, Dmitry Ilvokhin wrote:
> On Fri, Oct 24, 2025 at 09:38:53AM +0200, Michal Hocko wrote:
> > On Thu 23-10-25 18:12:02, Dmitry Ilvokhin wrote:
> > > Allow to override defaults for shemem 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.
> > 
> > Being consistent is usually nice but you are not telling us _who_ is
> > going to benefit from this. Increasing the config space is not really
> > free. So please focus on Why do we need it rather than it is consistent
> > argument.
> 
> Thanks for the feedback, Michal, totally make sense to me, I should have
> expand on this point in the initial commit message.
> 
> 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.

Please expand the changelog with this explanation. Thanks!

> 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.

With this information added, feel free to add
Acked-by: Michal Hocko <mhocko@suse.com>
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

[Lorenzo Stoakes]

On Thu, Oct 23, 2025 at 06:12:02PM +0000, Dmitry Ilvokhin wrote:
> Allow to override defaults for shemem 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.
>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>

This looks reasonable, thanks.

I guess one fly in the ointment is that these settings are only applicable
for those THP page sizes (both for anon and shmem) that are set to inherit,
but of course we default to this at startup so that's fine, just an
annoying point of confusion in THP generally :)

Based on your response to Michal, whose question is really at the crux of
this, LGTM, so:

Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

> ---
>  mm/Kconfig | 91 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  mm/shmem.c | 33 ++++++++++++++++++--
>  2 files changed, 122 insertions(+), 2 deletions(-)
>
> diff --git a/mm/Kconfig b/mm/Kconfig
> index e47321051d76..5ceea38edbe1 100644
> --- a/mm/Kconfig
> +++ b/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
> diff --git a/mm/shmem.c b/mm/shmem.c
> index eb8161136a7f..a411d7fb6e5a 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -570,8 +570,37 @@ static int shmem_confirm_swap(struct address_space *mapping, pgoff_t index,
>  #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,
> --
> 2.47.3
>

Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

[Pedro Falcato]

On Thu, Oct 23, 2025 at 06:12:02PM +0000, Dmitry Ilvokhin wrote:
> Allow to override defaults for shemem 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.

Why do you need these options instead of using CONFIG_CMDLINE?
They should pull off exactly what you want, but without changing the kernel?

-- 
Pedro

Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

[Matthew Wilcox]

On Fri, Oct 24, 2025 at 11:19:50AM +0000, Dmitry Ilvokhin wrote:
> 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

So you work for Meta?  It is poor form to send patches without
disclosing your employer.  That way, we'd all be able to see that the
positive reviews come from your colleagues rather than having it look
like everyone's just "oh, i'm a random developer doing this on my own
time".

Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

[Andrew Morton]

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,
_

Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

[Yafang Shao]

On Fri, Oct 24, 2025 at 7:23 PM Dmitry Ilvokhin <d@ilvokhin.com> wrote:
>
> On Fri, Oct 24, 2025 at 09:38:53AM +0200, Michal Hocko wrote:
> > On Thu 23-10-25 18:12:02, Dmitry Ilvokhin wrote:
> > > Allow to override defaults for shemem 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.
> >
> > Being consistent is usually nice but you are not telling us _who_ is
> > going to benefit from this. Increasing the config space is not really
> > free. So please focus on Why do we need it rather than it is consistent
> > argument.
>
> Thanks for the feedback, Michal, totally make sense to me, I should have
> expand on this point in the initial commit message.
>
> 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.

I'd like to better understand your kernel deployment strategy. Are you
maintaining separate kernel images for different environments in your
fleet? We've found that this approach can introduce significant
maintenance complexity in the build system.

In our practice, we standardize on a single kernel image across all
environments and handle variations through dynamic boot parameters.
This approach is quite straightforward to implement. If you're
concerned about uncontrolled environments, you could set default
values like shmem_enabled and tmpfs_enabled to 'never', then
explicitly enable them only in approved environments.

>
> 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.
>
> 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.
>

-- 
Regards
Yafang

Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

[Dmitry Ilvokhin]

On Fri, Oct 24, 2025 at 09:27:39PM +0100, Pedro Falcato wrote:
> On Thu, Oct 23, 2025 at 06:12:02PM +0000, Dmitry Ilvokhin wrote:
> > Allow to override defaults for shemem 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.
> 
> Why do you need these options instead of using CONFIG_CMDLINE?
> They should pull off exactly what you want, but without changing the kernel?

Thanks for the suggestion, Pedro. I think CONFIG_CMDLINE could work, but
for this purpose it doesn't seem ideal. Relying on CONFIG_CMDLINE isn't
a very scalable solution, since over time it tends to accumulate into a
long, unstructured string that isn't validated at build time. It also
mixes configuration layers: build-time policy and boot-time setup, which
makes the resulting behavior a bit harder to maintain in the long run.
So this approach is mainly about improving long-term maintainability and
operational clarity. I hope that makes sense.

> 
> -- 
> Pedro

Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

[Dmitry Ilvokhin]

On Sun, Oct 26, 2025 at 08:12:27PM +0800, Yafang Shao wrote:
> On Fri, Oct 24, 2025 at 7:23 PM Dmitry Ilvokhin <d@ilvokhin.com> wrote:
> >
> > On Fri, Oct 24, 2025 at 09:38:53AM +0200, Michal Hocko wrote:
> > > On Thu 23-10-25 18:12:02, Dmitry Ilvokhin wrote:
> > > > Allow to override defaults for shemem 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.
> > >
> > > Being consistent is usually nice but you are not telling us _who_ is
> > > going to benefit from this. Increasing the config space is not really
> > > free. So please focus on Why do we need it rather than it is consistent
> > > argument.
> >
> > Thanks for the feedback, Michal, totally make sense to me, I should have
> > expand on this point in the initial commit message.
> >
> > 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.
> 
> I'd like to better understand your kernel deployment strategy. Are you
> maintaining separate kernel images for different environments in your
> fleet? We've found that this approach can introduce significant
> maintenance complexity in the build system.

Thanks for the feedback, Yafang. To clarify, our goal isn't to maintain
separate kernel images for different environments, as we also prefer to
standardize on a single kernel binary wherever possible.

What we'd like to achieve with this change is a consistent baseline
policy for shmem/tmpfs at the lowest possible layer. In particular, we’d
like shmem/tmpfs hugepage usage to be an opt-out rather than an opt-in
behavior. That is, the kernel would default (likely madvise or
within_size, not to always) to using hugepages for shmem/tmpfs unless
explicitly disabled. This ensures desired behavior out of the box, while
still allowing overrides through boot parameters if needed for specific
environments.

> 
> In our practice, we standardize on a single kernel image across all
> environments and handle variations through dynamic boot parameters.
> This approach is quite straightforward to implement. If you're
> concerned about uncontrolled environments, you could set default
> values like shmem_enabled and tmpfs_enabled to 'never', then
> explicitly enable them only in approved environments.
> 
> >
> > 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.
> >
> > 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.
> >
> 
> -- 
> Regards
> Yafang

Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

[Dmitry Ilvokhin]

On Fri, Oct 24, 2025 at 09:35:34PM +0100, Matthew Wilcox wrote:
> On Fri, Oct 24, 2025 at 11:19:50AM +0000, Dmitry Ilvokhin wrote:
> > 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
> 
> So you work for Meta?  It is poor form to send patches without
> disclosing your employer.  That way, we'd all be able to see that the
> positive reviews come from your colleagues rather than having it look
> like everyone's just "oh, i'm a random developer doing this on my own
> time".

Thanks for the feedback, Matthew. For transparency: I work for Meta, and
this patch is being submitted as part of that work. I know it's common
for many contributors to submit work-related patches using personal
emails, but I can understand your point and appreciate the guidance.

Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

[David Hildenbrand]

On 27.10.25 17:23, Dmitry Ilvokhin wrote:
> On Fri, Oct 24, 2025 at 09:35:34PM +0100, Matthew Wilcox wrote:
>> On Fri, Oct 24, 2025 at 11:19:50AM +0000, Dmitry Ilvokhin wrote:
>>> 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
>>
>> So you work for Meta?  It is poor form to send patches without
>> disclosing your employer.  That way, we'd all be able to see that the
>> positive reviews come from your colleagues rather than having it look
>> like everyone's just "oh, i'm a random developer doing this on my own
>> time".
> 
> Thanks for the feedback, Matthew. For transparency: I work for Meta, and
> this patch is being submitted as part of that work. I know it's common
> for many contributors to submit work-related patches using personal
> emails, but I can understand your point and appreciate the guidance.

Note that Willy, for example, signs-off patches with

	Matthew Wilcox (Oracle) <willy@infradead.org>

-- 
Cheers

David / dhildenb