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

[David Hildenbrand (Arm)]

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

Exactly.

-- 
Cheers,

David