From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A39D37E312 for ; Fri, 20 Mar 2026 09:53:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774000401; cv=none; b=E/euyzKTWhbv9VyZOBzrQNE0dSY+Va5PbT8P10YNQLmehClz4b3c4MlDxHKJchhOUqvdwZgQjjtT+Fw1RrSBsjtWhPOy534sPxo4SnT3ljMatxdlDyQigWse/a+J7iGIVFHK6ZXmYXWfulcBAuk3tDkRRmbOGg0BlKUWFq0Iaiw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774000401; c=relaxed/simple; bh=G/D8/6l1J5EDvSsTgBB0ZrD/vkTc0vXii9mVW9ai2JQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=l+ljKi6giT8sh45Y8pDnc6lMiCGRi2uuCXAdUh6/sryvLekqx6+P01Imxk3KKoU/V6J3g5fVwPq/+fV3J8CVZu8Habi6X37j2gE2XJIFyFKvAjJs0wRxuczoHHqr5GJXMNyBg7/AvPhhla6mSvEX5+udwne+hs6lMDkaGob0ShY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Q0iheGUZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Q0iheGUZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C416C2BC9E; Fri, 20 Mar 2026 09:53:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774000401; bh=G/D8/6l1J5EDvSsTgBB0ZrD/vkTc0vXii9mVW9ai2JQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Q0iheGUZYk8Pire/FtxwUk+x/f0XJwRMaH/KqUGIxTpGVbpAPhNgvKzF+ql3F9xCA NYWTy/SU73hZeRLV/MhPxMi2fWVbZFlHyQ52GjAVLy/pPezcruyaKCPSWndqVKOGVH tAj298QCenbJC3vP3c7sTKbccJ0vC5mDZIg8sscD3wmkJTlMnbpwxPqnmjT2xk6KKS vyP+0ZAQc6b1wG673FQwCLlN7NZ/1SmYpUbIXihQZLoYXr+ZGVK3u2XdGIWn+R9L6S 8Nx4PF6hjEahvS9GU58yOAbI42PhgcbOtHSQfPkJIrxUBUZGdot+u5gGp5nfyuDa4g WZ7z5qoHGbTZQ== From: Pratyush Yadav To: Pasha Tatashin Cc: Chenghao Duan , rppt@kernel.org, pratyush@kernel.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, jianghaoran@kylinos.cn Subject: Re: [PATCH v1 1/3] mm/memfd_luo: optimize shmem_recalc_inode calls in retrieve path In-Reply-To: (Pasha Tatashin's message of "Thu, 19 Mar 2026 11:28:05 -0400") References: <20260319012845.29570-1-duanchenghao@kylinos.cn> <20260319012845.29570-2-duanchenghao@kylinos.cn> Date: Fri, 20 Mar 2026 09:53:17 +0000 Message-ID: <2vxzms02bzea.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 19 2026, Pasha Tatashin wrote: > On Wed, Mar 18, 2026 at 9:29=E2=80=AFPM 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. >> >> Signed-off-by: Chenghao Duan >> --- >> mm/memfd_luo.c | 9 ++++++++- >> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c >> index b8edb9f981d7..5ddd3657d8be 100644 >> --- a/mm/memfd_luo.c >> +++ b/mm/memfd_luo.c >> @@ -397,6 +397,7 @@ static int memfd_luo_retrieve_folios(struct file *fi= le, >> struct folio *folio; >> int err =3D -EIO; >> long i; >> + u64 nr_added =3D 0; > > nit: I perfer RCT for local variables order, but it is not followed in > this file anyway. It is though, for the most part. I also prefer this so as much as I could I followed it, but sometimes if you want to assign variables at declaration, it isn't always possible. Anyway, RCT would be nice to have indeed. [...] --=20 Regards, Pratyush Yadav