Re: [PATCH v2] tmpfs: fault in smaller chunks if large folio allocation not allowed

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

On 2024/9/30 10:30, Kefeng Wang wrote:
> 
> 
> On 2024/9/30 10:02, Baolin Wang wrote:
>>
>>
>> On 2024/9/26 21:52, Matthew Wilcox wrote:
>>> On Thu, Sep 26, 2024 at 10:38:34AM +0200, Pankaj Raghav (Samsung) wrote:
>>>>> So this is why I don't use mapping_set_folio_order_range() here, but
>>>>> correct me if I am wrong.
>>>>
>>>> Yeah, the inode is active here as the max folio size is decided 
>>>> based on
>>>> the write size, so probably mapping_set_folio_order_range() will not be
>>>> a safe option.
>>>
>>> You really are all making too much of this.  Here's the patch I think we
>>> need:
>>>
>>> +++ b/mm/shmem.c
>>> @@ -2831,7 +2831,8 @@ static struct inode *__shmem_get_inode(struct 
>>> mnt_idmap *idmap,
>>>          cache_no_acl(inode);
>>>          if (sbinfo->noswap)
>>>                  mapping_set_unevictable(inode->i_mapping);
>>> -       mapping_set_large_folios(inode->i_mapping);
>>> +       if (sbinfo->huge)
>>> +               mapping_set_large_folios(inode->i_mapping);
>>>
>>>          switch (mode & S_IFMT) {
>>>          default:
>>
>> IMHO, we no longer need the the 'sbinfo->huge' validation after adding 
>> support for large folios in the tmpfs write and fallocate paths [1].
>>
>> Kefeng, can you try if the following RFC patch [1] can solve your 
>> problem? Thanks.
>> (PS: I will revise the patch according to Matthew's suggestion)
> 
> Sure, will try once I come back, but [1] won't solve the issue when set

Cool. Thanks.

> force/deny at runtime, eg, mount with always/within_size, but set deny 
> when runtime, we still fault in large chunks, but we can't allocate 
> large folio, the performance of write will be degradation.

Yes, but as Hugh mentioned before, the options 'force' and 'deny' are 
rather testing artifacts from the old ages. So I suspect if the 'deny' 
option will be set in the real products, that means do we really need 
consider this case too much?