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 17DB536829F for ; Mon, 19 Jan 2026 13:44:54 +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=1768830295; cv=none; b=R7UWpquN+7neKHNURLirBkWCwCKoIjyysxWB0G3EtQ4evhUq4Hbe36HPhJoUW6VPsbWqazVNg9f1JNn9jusztRnDwpCwQBZDwZPr4t727DxWG3Y9rGcLfZ7ACsONmwTFrb3YjUbOEtCjIqYJwehSPiLfQEQeRuyMdfMHTumV6Oo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768830295; c=relaxed/simple; bh=xRH7BMwvRGAtAUjRAN0eWnx0hTH99JQz2hozrDCX5yc=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=m+mYA3VK+l0vVdsswgrPaXpo8P/hygSl31i/XUQgvXo2im0pehth9qYQ1fnEx2pSwc9a7gYRdxTH9o9UXLinJ6o+2i76AZ8vIK1vMHa2VLctK6zLdNAJfpIwAKfQFNqozVB3w/vsd5iNC5BQIXWpJNT4fy2TVrtrxJyM2Gg1MmQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nPxAVETI; 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="nPxAVETI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B655AC116C6; Mon, 19 Jan 2026 13:44:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768830294; bh=xRH7BMwvRGAtAUjRAN0eWnx0hTH99JQz2hozrDCX5yc=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=nPxAVETIUl3BJxS2k8r51TyOaQFoiZIdVxG54tQnbRDKCQvD7LeMLp73vWBCHwxcc Ws+TI71YmSVL8Rt/5/plhJbMAtXXuTbfKB4l+BwCHUmh+3IGdEeDIZRhlezzlt/F/2 0Mz5gGCO9r5ZpA+/qkbGoZSTt3G2bFNSl4nvO1A6i9ncHCkgJzddusJuPouJ833Vmm Jw75BUKBQ9fIaHeGUw+DHQ6B1CpjSnEPN21+t5N6X9BAt6ryrTCdRF6bydahd+CG7p CfkhEh6mYLAipAP8qYK0FHn6YFB61VnsL3HztggVnPgBygGc2LTrhyUBVmZWiCqYgA 4UJHIF/xPSbjw== Message-ID: Date: Mon, 19 Jan 2026 21:44:48 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: chao@kernel.org, jaegeuk@kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: Re: [f2fs-dev] [PATCH] f2fs: avoid f2fs_map_blocks() for consecutive holes in readpages To: Nanzhe Zhao References: <20260112013320.8028-1-chao@kernel.org> <5e888451-228e-41e5-ada7-a22a61cb84dd@126.com> <32fa7311-0393-4e71-a927-3c502e40efd8@kernel.org> <6d6b3bad.5f72.19bd535bd6d.Coremail.nzzhao@126.com> Content-Language: en-US From: Chao Yu In-Reply-To: <6d6b3bad.5f72.19bd535bd6d.Coremail.nzzhao@126.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/19/2026 3:43 PM, Nanzhe Zhao wrote: > Hi Chao: > At 2026-01-16 16:52:02, "Chao Yu" wrote: >>> >>> Do we have plans to also support reducing f2fs_map_blocks() calls for >>> consectives holes in logical file postion with dnode have already been >>> allocated in buffered large folio read? >>> Such as consective NULL_ADDR or NEW_ADDR? >> >> Nanzhe, >> >> We have supported that for large folio read w/ this patch? >> >> Thanks, >> > > Sorry, I'm a bit confused. > In the condition of F2FS_MAP_BLOCK_DEFAULT, the default: case will only > set map->m_next_pgofs to pgofs + 1 then sync out. When we enter > next iteration and the index advanced, currrent index now turns to pgofs + 1 > and index < next_pgofs become false.In consequence, we won't reduce > f2fs_map_blocks() calls for hole with dnode allocated. > > Also, for NEW_ADDR, the default: case will directly go to sync out and bypass > map_is_mergeable, so it will also not reduce f2fs_map_blocks calls. > > Or am I missing something? I guess f2fs_map_no_dnode() will update map->m_next_pgofs to pgofs of next potential valid dnode. Thanks, > > Thanks, > Nanzhe Zhao