Re: [PATCH] mm: shmem: fix too little space for tmpfs only fallback 4KB

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

On 2025/9/9 20:29, Vernon Yang wrote:
> 
> 
>> On Sep 9, 2025, at 13:58, Baolin Wang <baolin.wang@linux.alibaba.com> wrote:
>>
>>
>>
>> On 2025/9/8 20:31, Vernon Yang wrote:
>>> From: Vernon Yang <yanglincheng@kylinos.cn>
>>> When the system memory is sufficient, allocating memory is always
>>> successful, but when tmpfs size is low (e.g. 1MB), it falls back
>>> directly from 2MB to 4KB, and other small granularity (8KB ~ 1024KB)
>>> will not be tried.
>>> Therefore add check whether the remaining space of tmpfs is sufficient
>>> for allocation. If there is too little space left, try smaller large
>>> folio.
>>
>> I don't think so.
>>
>> For a tmpfs mount with 'huge=within_size' and 'size=1M', if you try to write 1M data, it will allocate an order 8 large folio and will not fallback to order 0.
>>
>> For a tmpfs mount with 'huge=always' and 'size=1M', if you try to write 1M data, it will not completely fallback to order 0 either, instead, it will still allocate some order 1 to order 7 large folios.
>>
>> I'm not sure if this is your actual user scenario. If your files are small and you are concerned about not getting large folio allocations, I recommend using the 'huge=within_size' mount option.
>>
> 
> No, this is not my user scenario.
> 
> Based on your previous patch [1], this scenario can be easily reproduced as
> follows.
> 
> $ mount -t tmpfs -o size=1024K,huge=always tmpfs /xxx/test
> $ echo hello > /xxx/test/README
> $ df -h
> tmpfs            1.0M  4.0K 1020K   1% /xxx/test
> 
> The code logic is as follows:
> 
> shmem_get_folio_gfp()
>      orders = shmem_allowable_huge_orders()
>      shmem_alloc_and_add_folio(orders) return -ENOSPC;
>          shmem_alloc_folio() alloc 2MB
>          shmem_inode_acct_blocks()
>              percpu_counter_limited_add() goto unacct;
>          filemap_remove_folio()
>      shmem_alloc_and_add_folio(order = 0)
> 
> 
> As long as the tmpfs remaining space is too little and the system can allocate
> memory 2MB, the above path will be triggered.

In your scenario, wouldn't allocating 4K be more reasonable? Using a 1M 
large folio would waste memory. Moreover, if you want to use a large 
folio, I think you could increase the 'size' mount option. To me, this 
doesn't seem like a real-world usage scenario, instead it looks more 
like a contrived test case for a specific situation.

Sorry, this still doesn't convince me.