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

["Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>]

On Mon, Sep 23, 2024 at 09:39:07AM +0800, Kefeng Wang wrote:
> 
> 
> On 2024/9/22 8:35, Matthew Wilcox wrote:
> > On Fri, Sep 20, 2024 at 10:36:54PM +0800, Kefeng Wang wrote:
> > > The tmpfs supports large folio, but there is some configurable options
> > > to enable/disable large folio allocation, and for huge=within_size,
> > > large folio only allowabled if it fully within i_size, so there is
> > > performance issue when perform write without large folio, the issue is
> > > similar to commit 4e527d5841e2 ("iomap: fault in smaller chunks for
> > > non-large folio mappings").
> > 
> > No.  What's wrong with my earlier suggestion?
> > 
> 
> The tempfs has mount options(never/always/within_size/madvise) for large
> folio, also has sysfs file /sys/kernel/mm/transparent_hugepage/shmem_enabled
> to deny/force large folio at runtime, as replied in v1, I think it
> breaks the rules of mapping_set_folio_order_range(),
> 
>   "Do not tune it based on, eg, i_size."
>   --- for tmpfs, it does choose large folio or not based on the i_size
> 
>   "Context: This should not be called while the inode is active as it is
> non-atomic."
>   --- during perform write, the inode is active
> 
> 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.