Re: [PATCH v3] mm: shmem: always support large folios for internal shmem mount

[David Hildenbrand (Arm)]

On 4/17/26 14:45, Baolin Wang wrote:
> 
> 
> On 4/17/26 5:52 PM, David Hildenbrand (Arm) wrote:
>> On 4/17/26 11:27, Baolin Wang wrote:
>>>
>>>
>>>
>>> For tmpfs, yes.
>>
>> So, we could pass this check here, not setting
>> mapping_set_large_folios(), but later someone toggles it and we missed
>> to set mapping_set_large_folios()?
> 
> Indeed. Good point.
> 
>>
>> Or would we always go through another __shmem_get_inode() after a
>> remount?
> 
> Not really. There could be files created before remount whose mappings
> don't support large folios (with 'huge=never' option), while files
> created after remount will have mappings that support large folios (if
> remounted with 'huge=always' option).
> 
> It looks like the previous commit 5a90c155defa was also problematic. The
> huge mount option has introduced a lot of tricky issues:(
> 
> Now I think Zi's previous suggestion should be able to clean up this
> mess? That is, calling mapping_set_large_folios() unconditionally for
> all shmem mounts, and revisiting Kefeng's first version to fix the
> performance issue.

Okay, so you'll send a patch to just set mapping_set_large_folios()
unconditionally?

> 
> [1] https://lore.kernel.org/all/20240914140613.2334139-1-
> wangkefeng.wang@xxxxxxxxxx/

Is that really required? Which call path would be the problematic bit
with the above?

I'd say, we'd check in the large folio allocation code whether ->huge is
set to never instead?

-- 
Cheers,

David