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

[Kefeng Wang <wangkefeng.wang@huawei.com>]

On 2024/9/30 10:52, Baolin Wang wrote:
> 
> 
> 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].

Forget to mention, we still need to check sbinfo->huge, if mount with
huge=never, but we fault in large chunk, write is slower than without
9aac777aaf94, the above changes or my patch could fix it.

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

OK, so maybe just update the document.