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

[Zi Yan <ziy@nvidia.com>]

On 16 Apr 2026, at 4:44, David Hildenbrand (Arm) wrote:

> 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.

Sounds good to me too.


Best Regards,
Yan, Zi