From nobody Mon Jun 8 13:31:22 2026 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A3AD6340402 for ; Fri, 29 May 2026 02:29:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.178 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780021771; cv=none; b=Mxx2tEIiLwGoJl0nLPTQhpNzgJYH1HBcU47JgaYBLg+NBwTXEBwI2ylwaupb7Rhe1Yzej1OlWd0S11k5Hgybu7sDW6vzRSAGJIQ56CpeatHqhYLzZIVZSt1b0RjxeUZmTvK75anCfoP0HIQ8KnKh06l8ffpSPzwI93HvfHBiAb4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780021771; c=relaxed/simple; bh=4454gHs8/QcbtjyJ7GON3f0oxjneceydaeo6natMPY0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=PQxsga8YPqWaTR0LPrsaXc+aMjmrcUh8Hzr983x8T84yySaqYV3Dnorefa0YcEAyxjpJGFHdbHaq0VfTHshy0eiD9n5oCCEom175Hn1ysjXGDFAuulFIcZP2UEdfTd/sAcxYWNW6UBR/fUvZU8CuEcJauf4xz9UPQ2K3zHNhGB4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hPAonriW; arc=none smtp.client-ip=209.85.214.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hPAonriW" Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-2bf22d29dabso922075ad.2 for ; Thu, 28 May 2026 19:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780021770; x=1780626570; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=8ZOkaYrqky10WkHIDKr7bJwwYWzRRoO9WOSbHh2V/Zw=; b=hPAonriW9W2q0Mj8RkLbDCn1dDF9b5DDDZk0fn7VUOJ0yplkVv12EBtVdJ2PSeywFh 7NOxHSSmQFWabvSFn9FsyYlx9MD+oI86zPPqWrz8v3nm9INqgG4mf6TtlZNMGDQy2sol ne9wjm9vnxOEVvBQ50+9xuwpmaorUR8qANN0mcOI2o4pwvPTaPAJkPTpExS21169KSmx FAZSdSvm9IJj9RqFvWqgiDGdzH/HZ8/cDHJ8GrpX/4b0LmjbZVCjK3yce8vwILxEFs9f rylMgDNsQ52CVCXdIc5YMwMojA/OzAlqbGlbXORXLSVl1avTGfcts/CNo1SG2HJy9X/c TQuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780021770; x=1780626570; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8ZOkaYrqky10WkHIDKr7bJwwYWzRRoO9WOSbHh2V/Zw=; b=RfOyH8PoEv8suaXVQYbdgT9OUIZA08EEcTeZp9GHmB9B+hNjQ0iFYRv+D05r5w5YSf nUff42sLM+1uGwDyV/ZID5dZw8LePItkvEZRXT4pqinpe0BcW2TXoRInmZN0ZnKF2sDQ 2Lum0bCCo6EBNw0n5Z3426neWljMHGCNDtKWx3PuUT/qHAqA1eGadnn4WFPxKDoQKMuB MdtSILeBHWUdyeUDB/aj5SW9+Fwai2No2gLittWvbUpgzB8eFZTyLbM0tMWYCAmaQeCE CUG3YP3mLw1BtObGwdnujUKTXb/iANBWEbif9BUbRg2BZGwCazy2mLR8EMOr53VYRVZP pabg== X-Forwarded-Encrypted: i=1; AFNElJ+REpOH+BjBFCJUwhxfRCHu+NjO+tr1GQO2LfSuOZhsG213hOZLJtw3O9kfXBX+ckbcKGC087LsKcdvYbU=@vger.kernel.org X-Gm-Message-State: AOJu0YxzBAKuJfetajQDvMOltc/VQuwEMkrwnqc7SYnXBhyN84YJ+8NS D+IrwRlOpNkkr0tzkIiO8BtAU1VAqE7eryc/RpKEUwUL+/gb6SXTVCXd X-Gm-Gg: Acq92OGq6IZ4HT3QUPY4fUeE623EGQOw+rPb6q8wOX5HJjqTE7txBl3wzy/Oj+RjmR5 h3JbXiED1z/sK/vzHL48RwlaXAcBV38BLoeA3+nGiB/YoNddoCSwEDtIoHVjyW0z2kXc18G3V5i mcY+HCkUNVJfFQX+BR5DONpj1a/lvP6wZBqC5p9T5dPAu5VD++ui85AcxN5Akt63w+BnU9OrE6y pKwqabjzDqsy6WUBzs2WQ8NchlxxLzL/uldhVJ8kcr9qJlkLdMP3v1wVZ2ZYWLWDvrFOh4s02Vp nJyVkvLCEllyDDIxZt/VEhrv78tSp3jdzgQ1dtaCJx7L/p/37ko59Cqkq9fjAL45oqfyyxQpaW+ ++ATTlWoWdvdFmprc1b8FDAHI+ouwkH0C+SogiUzDLzXkr1V/t0NKTvcPGbLMS/j34d+petSqx9 7TabO2Jx/XOQGpZzIqLLKuwiyViEf8Za+9FPasMJljNlWG7WlvfxLcUGFspQC/l6pyi5MkBA== X-Received: by 2002:a17:902:fc48:b0:2bd:8822:d8cb with SMTP id d9443c01a7336-2bf209b0cf6mr12616285ad.23.1780021769903; Thu, 28 May 2026 19:29:29 -0700 (PDT) Received: from qiwenjie-ThinkCentre-M760t.mioffice.cn ([43.224.245.241]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2bf23c2da36sm1375735ad.69.2026.05.28.19.29.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 May 2026 19:29:29 -0700 (PDT) From: Wenjie Qi X-Google-Original-From: Wenjie Qi To: jaegeuk@kernel.org, chao@kernel.org Cc: linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, qiwenjie@xiaomi.com, qwjhust@gmail.com Subject: [PATCH] f2fs: skip inode folio lookup for cached overwrite Date: Fri, 29 May 2026 10:29:24 +0800 Message-ID: <20260529022924.3655519-1-qiwenjie@xiaomi.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 --- fs/f2fs/data.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index d83a21998ec2..3b32f9b75b77 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -3719,6 +3719,11 @@ static int prepare_write_begin(struct f2fs_sb_info *= sbi, int flag =3D F2FS_GET_BLOCK_PRE_AIO; int err =3D 0; =20 + if (!f2fs_has_inline_data(inode) && !f2fs_compressed_file(inode) && + (pos & PAGE_MASK) < i_size_read(inode) && + f2fs_lookup_read_extent_cache_block(inode, index, blk_addr)) + return 0; + /* * If a whole page is being written and we already preallocated all the * blocks, then there is no need to get a block address now. --=20 2.43.0