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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aPtg1vUnpkaK1Ce5@shell.ilvokhin.com>
Date: Fri, 24 Oct 2025 11:19:50 +0000
From: Dmitry Ilvokhin <d@...okhin.com>
To: Michal Hocko <mhocko@...e.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	David Hildenbrand <david@...hat.com>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Hugh Dickins <hughd@...gle.com>,
	Baolin Wang <baolin.wang@...ux.alibaba.com>,
	Kiryl Shutsemau <kas@...nel.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

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