linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Ilvokhin <d@ilvokhin.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	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: Fri, 24 Oct 2025 11:19:50 +0000	[thread overview]
Message-ID: <aPtg1vUnpkaK1Ce5@shell.ilvokhin.com> (raw)
In-Reply-To: <aPstDXRerYqi1O2X@tiehlicka>

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


  reply	other threads:[~2025-10-24 11:19 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 [this message]
2025-10-24 11:57     ` Michal Hocko
2025-10-26  4:29       ` Andrew Morton
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=aPtg1vUnpkaK1Ce5@shell.ilvokhin.com \
    --to=d@ilvokhin.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.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