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 C8CB239C002 for ; Thu, 16 Apr 2026 09:35:18 +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=1776332118; cv=none; b=T7QYKBAAxqHT9eJSNjdpFZrcluQCn8AjmEvxe4b2EpzodwsDFswPXG0brHa+G9XPRd5KX3hLrjHXLysZTPGq7+iRZ1clN23Gl0u2FbobrPyr3LWbhVNEWL5bl/QGNy/ab2Iu+Mmc7EPmLuhoreiYHgqcHcRmXVzwBGlCcccyjk0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776332118; c=relaxed/simple; bh=qzx86yIYEM/GemLvFCh/lwiEzuYxSCpGtYSGjiBaBAY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=bxHTB2S4RlTYyUWVZFbslw2kkrgqQ49NFEzhVGktEqLRFvo7VXiQvAZS93DcNR6snW44RPf940+8x2fl6ud73+Vns6aT4BxB6sHw+WgO85APkH1FLXsuZkVRknN5p6pwnGpfaFnMxSANZJoQPHLq5sasr6zEUAM9JxE79lZhMcU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V2OY/WXd; 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="V2OY/WXd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45FA3C2BCAF; Thu, 16 Apr 2026 09:35:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776332118; bh=qzx86yIYEM/GemLvFCh/lwiEzuYxSCpGtYSGjiBaBAY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=V2OY/WXd/jcvmTN+lN0/LtgwDqPt1EqOT/yVI1PrNnh/fI7foPgvgxdGx54kwKGKN E/2Ggvpn6n2OZ7eyYF3SzeoST/lwZ8wYWbdjUB0YidY5dw+8qU+W0VoGe/tIZGXyvK W1AIYLxoYYnU1LFW965p0UTthgAyMyiObDfnDoG/NpMwVwRxd3j5G0cRxPApZEW5y9 Y5NluBS9bpV12u/Vj4npXYp36Jb7M1zF50aFMy/lPFg8eYGFSlO9cCFffS3jdo0ZrQ bEgwNIdp2af7qzaBYnor+rcBtHDPBYCEOTxmQzmxr4AaoPeH4ebZ69LysVK79NtLWu 3YYlqzcFxQBAg== From: Pratyush Yadav To: Chenghao Duan Cc: Pratyush Yadav , pasha.tatashin@soleen.com, rppt@kernel.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, jianghaoran@kylinos.cn Subject: Re: [PATCH v3 2/7] mm/memfd_luo: optimize shmem_recalc_inode calls in retrieve path In-Reply-To: <20260410014537.GA28528@chenghao-pc> (Chenghao Duan's message of "Fri, 10 Apr 2026 09:45:37 +0800") References: <20260326084727.118437-1-duanchenghao@kylinos.cn> <20260326084727.118437-3-duanchenghao@kylinos.cn> <2vxz8qb5hbgz.fsf@kernel.org> <20260410014537.GA28528@chenghao-pc> Date: Thu, 16 Apr 2026 09:35:14 +0000 Message-ID: <2vxzse8v6yel.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 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 >> > Signed-off-by: Chenghao Duan >> >> Reviewed-by: Pratyush Yadav >> >> 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