From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Baolin Wang <baolin.wang@linux.alibaba.com>,
akpm@linux-foundation.org, hughd@google.com
Cc: willy@infradead.org, ziy@nvidia.com, ljs@kernel.org,
lance.yang@linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] mm: shmem: always support large folios for internal shmem mount
Date: Fri, 17 Apr 2026 11:21:08 +0200 [thread overview]
Message-ID: <1b3c0401-6d10-4a28-97c8-8e3858d8dc3d@kernel.org> (raw)
In-Reply-To: <26f954be62348591e720c4e8b7a9099b74dc1d6d.1776331555.git.baolin.wang@linux.alibaba.com>
On 4/17/26 05:25, Baolin Wang wrote:
> Currently, when shmem mounts are initialized, they only use 'sbinfo->huge' to
> determine whether the shmem mount supports large folios. However, for anonymous
> shmem, whether it supports large folios can be dynamically configured via sysfs
> interfaces, so setting or not setting mapping_set_large_folios() during initialization
> cannot accurately reflect whether anonymous shmem actually supports large folios,
> which has already caused some confusion[1].
>
> As discussed with David[2], for anonymous shmem we can treat it as always potentially
> having large folios. Therefore, always support large folios for the internal shmem
> mount (e.g., anonymous shmem), and which large order allocations are allowed can be
> configured dynamically via the 'shmem_enabled' interfaces.
>
> [1] https://lore.kernel.org/all/ec927492-4577-4192-8fad-85eb1bb43121@linux.alibaba.com/
> [2] https://lore.kernel.org/all/875dc63b-0cd2-49e5-8b0d-3fb062789813@kernel.org/
> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> ---
> Changes from v2:
> - Always support large folios for internal shmem mount, per David.
> Changes from v1:
> - Update the comments and commit message, per Lance.
> ---
> mm/shmem.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 4ecefe02881d..769ef37b1ea9 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -3088,8 +3088,17 @@ static struct inode *__shmem_get_inode(struct mnt_idmap *idmap,
> if (sbinfo->noswap)
> mapping_set_unevictable(inode->i_mapping);
>
> - /* Don't consider 'deny' for emergencies and 'force' for testing */
> - if (sbinfo->huge)
> + /*
> + * Always support large folios for the internal shmem mount (e.g.,
> + * anonymous shmem), and which large order allocations are allowed
> + * can be configured dynamically via the 'shmem_enabled' interfaces.
> + *
> + * For tmpfs, honour the 'huge=' mount option to determine whether
> + * large folios are supported.
> + *
> + * Note: don't consider 'deny' for emergencies and 'force' for testing.
> + */
> + if (sbinfo->huge || (sb->s_flags & SB_KERNMOUNT))
> mapping_set_large_folios(inode->i_mapping);
Two questions from a non-fs person about the semantics here:
a) Can sbinfo->huge be triggered later, for example, through a remount
(staring at shmem_reconfigure())
b) Do we cover all cases with the SB_KERNMOUNT where sbinfo->huge cannot
be changed later?
--
Cheers,
David
next prev parent reply other threads:[~2026-04-17 9:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-17 3:25 Baolin Wang
2026-04-17 9:21 ` David Hildenbrand (Arm) [this message]
2026-04-17 9:27 ` Baolin Wang
2026-04-17 9:52 ` David Hildenbrand (Arm)
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=1b3c0401-6d10-4a28-97c8-8e3858d8dc3d@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=hughd@google.com \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/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