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

[Baolin Wang <baolin.wang@linux.alibaba.com>]

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);