Re: [PATCH v2] mm: shmem: don't set large-order range for internal shmem mount

[Baolin Wang]

On 4/15/26 5:54 PM, David Hildenbrand (Arm) wrote:
> > > > As I mentioned, the original logic has several issues for anonymous
> > > > shmem:
> > > >
> > > > 1. Whether anonymous shmem supports large folios can be dynamically
> > > > configured via sysfs interfaces, so mapping_set_large_folios() set
> > > > during initialization cannot accurately reflect whether anonymous shmem
> > > > actually supports large folios.
> > >
> > > Well, the mapping does support large folios, just the folio allocations
> > > are currently disable.
> > >
> > > It feels cleaner to say "there might be large folios in this mapping"
> > > than saying "there are no large folios in the mapping as the mapping
> > > does not support it", no?
> >
> > Yes, that makes sense.
> >
> > However, it’s also possible that the mapping does not support large
> > folios, yet anonymous shmem can still allocate large folios via the
> > sysfs interfaces. That doesn't make sense, right?
>
> That's what I am saying: if there could be large folios in there, then
> let's tell the world.
>
> Getting in a scenario where the mapping claims to not support large
> folios, but then we have large folios in there is inconsistent, not?
>
> [...]
>
> > > What if we say:
> > >
> > > shmem that *will never have*/*does never allow* large folios never sets
> > > mapping_set_large_folios().
> > >
> > > shmem that *might* have large folios (in the past, now, or in the
> > > future) sets mapping_set_large_folios().
> >
> > For the current anonymous shmem (tmpfs is already clear, no questions),
> > I don’t think there will be any "will never have/does never allow"
> > cases, because it can be changed dynamically via the sysfs interfaces.
>
> Right. It's about non-anon shmem with huge=off.
>
> > If we still want that logic, then for anonymous shmem we can treat it as
> > always "might have large folios".

OK. To resolve the confusion about 1, the logic should be changed as 
follows. Does that make sense to you?

if (sbinfo->huge || (sb->s_flags & SB_KERNMOUNT))
	mapping_set_large_folios(inode->i_mapping);