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

[David Hildenbrand (Arm)]

On 4/16/26 04:08, Baolin Wang wrote:
> 
> 
> On 4/16/26 9:52 AM, Zi Yan wrote:
>> On 15 Apr 2026, at 21:45, Baolin Wang wrote:
>>
>>>
>>> Personally, I still prefer the current fix (commit 5a90c155defa). We
>>> should honor the tmpfs mount option. If it explicitly says no large
>>> folios, we shouldn’t call mapping_set_large_folios(). Isn’t that more
>>> consistent with its semantics?
>>
>> Filesystems wishing to turn on large folios in the pagecache should call
>> ``mapping_set_large_folios`` when initializing the incore inode.
>>
>> You mean tmpfs with huge option set is a FS wishing to turn on large
>> folios in the pagecache, otherwise it is a FS wishing not to have
>> large folio
>> in the pagecache. tmpfs with different options is seen as different FSes.
> 
> What I mean is that tmpfs is somewhat different from other filesystems.
> We have tried to make tmpfs behave like other FSes, but differences
> remain. For example, the previous fix to tmpfs’s large folio allocation
> policy, see commit 69e0a3b49003 ("mm: shmem: fix the strategy for the
> tmpfs 'huge=' options").
> 
> So the tmpfs specific 'huge=' mount option is another way it differs
> from other filesystems.

Personally I'm fine just not calling mapping_set_large_folios() on
mappings where there must not ever be large folios.

But for every other mapping where there might be large folios at some
point, we should just set it.

-- 
Cheers,

David