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

[Pratyush Yadav]

On Fri, Apr 10 2026, Chenghao Duan wrote:

> 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@xxxxxxxxxx>
>> > Signed-off-by: Chenghao Duan <duanchenghao@xxxxxxxxxx>
>> 
>> Reviewed-by: Pratyush Yadav <pratyush@xxxxxxxxxx>
>> 
>> 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.

Okay, fair enough. Thanks for looking into it.

-- 
Regards,
Pratyush Yadav