Re: [PATCH v3] mm: shmem: always support large folios for internal shmem mount

[Baolin Wang]

On 4/17/26 5:21 PM, David Hildenbrand (Arm) wrote:
> 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@xxxxxxxxxxxxxxxxx/
> > [2] https://lore.kernel.org/all/875dc63b-0cd2-49e5-8b0d-3fb062789813@xxxxxxxxxx/
> > Signed-off-by: Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>
> > ---
> > 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())

For tmpfs, yes.

> b) Do we cover all cases with the SB_KERNMOUNT where sbinfo->huge cannot
> be changed later?

For mounts with the SB_KERNMOUNT flag set, which is essentially the 
internal shmem mount, as we discussed, we don't care about sbinfo->huge. 
Because for the internal shmem mount, we always consider it as 
potentially having large folios.