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

[Yafang Shao <laoar.shao@gmail.com>]

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