From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 62AA433F383 for ; Mon, 15 Jun 2026 10:43:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781520232; cv=none; b=TS6ck5ULkyN7gMHW+JAqg+5zUqfeQjoTpEtR0Y09OsTynclUjco7rUQ6SeLrrSDK2LR5CpMCMxkAsA3CNCtxHZHVh0AouQChD9eV8IchcaF3lyvaSq4r+JvYhaU9uY4EyuVgtugc8FBZW4o4dMs56gFJdJdrXotYluKTQFD5xsE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781520232; c=relaxed/simple; bh=cgF2uee2UUPkWhRaS8phY9wz8IwUWSzGp9XNTu9VIa4=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=hJ7QU9PtdEM1C+g+R6YQ2dXT/44VPBqM6uZeQD0t0hiaVB/tEkarmyhTn97eV3kH/k3SzRdgKhPuUTldTQgwLkWxaeZ0rJZJA2/JiG599DyZExvgal07rOziFcUfb7YkcObDEmwkhlVD7tHeVtBr0a6sGmmF5qw3FiFked3T838= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YdQicPmK; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YdQicPmK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF0FC1F000E9; Mon, 15 Jun 2026 10:43:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781520230; bh=3epWikBLnKvL0xfba2AN4mFxD0a92PCzLmZobS6U4tc=; h=Date:Cc:Subject:To:References:From:In-Reply-To; b=YdQicPmKLzODTRb4v4UUOXFNR3uXYe9mGfoHjJeD/dDZsFCdDOp+DfqBRvIi4GScU GJaYb+5DpJQ1/RlUQejZqOFSY62J3emmyNZqJLx/cPXIveQ9FSfp5Re6W0hQJUL0N4 i7Alvz6D5kEB+P74uHIn8x4qvCN96CX44JHg29UI2jyueTGdUOypiYgOiGiwnDHaJb 3dX4WwpRQ/rNdbCnkWc+hLhI+RldfR89ofiTzoyGzyvLbVTwkrop/eM9412bn7b0Ng ics4mnmrofniW5K4tJZbY0BKJZ1m/CkFasGtNRcIctNKVrC+F9oEv6RZur0mePDxYv BHptGAToDDbAQ== Message-ID: Date: Mon, 15 Jun 2026 18:43:47 +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, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, qiwenjie@xiaomi.com Subject: Re: [PATCH] f2fs: skip inode folio lookup for cached overwrite To: Wenjie Qi , jaegeuk@kernel.org References: <20260529022924.3655519-1-qiwenjie@xiaomi.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20260529022924.3655519-1-qiwenjie@xiaomi.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/29/26 10:29, Wenjie Qi wrote: > prepare_write_begin() first gets the inode folio and builds a dnode, > then checks the read extent cache. For an ordinary overwrite of a > non-inline and non-compressed file, an extent-cache hit already gives the > data block address and the following path does not need to allocate or > update any node state. > > Check the read extent cache before fetching the inode folio for that > narrow case. Keep the existing paths for inline data, compressed files, > and writes that may extend past EOF, where the helper may need inline > conversion, compression preparation, or block reservation. > > This avoids a node-folio lookup in the buffered overwrite fast path when > the mapping is already cached. > > In a QEMU/KASAN x86_64 VM, using a small buffered overwrite workload on > an existing 1MiB file, median time improved as follows: > > 64-byte overwrites: 1724.93 ns/write -> 1560.24 ns/write > 256-byte overwrites: 1713.38 ns/write -> 1577.85 ns/write > > Function profiling of 20k 64-byte overwrites showed > f2fs_get_inode_folio() calls drop from 20004 to 4. > > Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Thanks,