Re: [PATCH v3 2/7] mm/memfd_luo: optimize shmem_recalc_inode calls in retrieve path

[Chenghao Duan <duanchenghao@kylinos.cn>]

On Thu, Apr 02, 2026 at 11:02:04AM +0000, Pratyush Yadav wrote:
> On Thu, Mar 26 2026, Chenghao Duan wrote:
> 
> > Move shmem_recalc_inode() out of the loop in memfd_luo_retrieve_folios()
> > to improve performance when restoring large memfds.
> >
> > Currently, shmem_recalc_inode() is called for each folio during restore,
> > which is O(n) expensive operations. This patch collects the number of
> > successfully added folios and calls shmem_recalc_inode() once after the
> > loop completes, reducing complexity to O(1).
> >
> > Additionally, fix the error path to also call shmem_recalc_inode() for
> > the folios that were successfully added before the error occurred.
> >
> > Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> > Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
> 
> Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
> 
> BTW, can we also do the same for shmem_inode_acct_blocks() it the call
> to it can also be aggregated in the same way? You don't have to do it in
> this series, but possibly as a follow up.
> 
Thanks for pointing that out.

We can move shmem_recalc_inode() outside the loop for aggregation, as it
performs a single inode state update for the folios.

In contrast, shmem_inode_acct_blocks() is a validation step for resource
reservation, quota, and block accounting. Since it can fail on its own,
aggregating it outside the loop would complicate the error handling and
rollback paths, especially when only a subset of folios have been restored.

BRs
Chenghao
> [...]
> 
> -- 
> Regards,
> Pratyush Yadav