From: Chao Yu <chao@kernel.org>
To: Wenjie Qi <qwjhust@gmail.com>, jaegeuk@kernel.org
Cc: chao@kernel.org, linux-f2fs-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, qiwenjie@xiaomi.com
Subject: Re: [PATCH v2 0/2] f2fs: enable buffered RWF_DONTCACHE
Date: Fri, 21 Aug 2026 09:50:02 +0800 [thread overview]
Message-ID: <15a3ea00-8f50-4673-b445-1c83b1369ae8@kernel.org> (raw)
In-Reply-To: <20260820071438.695893-1-qiwenjie@xiaomi.com>
On 8/20/26 15:14, Wenjie Qi wrote:
> This series enables buffered RWF_DONTCACHE on F2FS for sustained one-pass
> streaming writes, where retaining the written data can displace more useful
> cache.
>
> Patch 1 keeps normal and dropbehind folios in separate write bios and
> defers dropbehind completion unless it runs in preemptible task context.
> Its eligibility check matches the proposed bio_in_atomic() helper instead
> of checking only in_task().
>
> Patch 2 passes FGP_DONTCACHE to the F2FS buffered write folio lookup and
> advertises FOP_DONTCACHE.
>
> Tests were run on a Xiaomi phone with 10.7 GiB of kernel-visible memory,
> running Android 16 and Linux 6.12.69 with 4 KiB pages. /data used F2FS.
>
> The performance test wrote exactly 64 GiB per run at 4 KiB,
> 8 KiB, 16 KiB, 32 KiB, 64 KiB, 128 KiB, 256 KiB, 512 KiB, and 1 MiB.
> Two counterbalanced rounds ran ascending normal-first and descending
> dontcache-first. Values below are equal-weight means of both runs; N=2.
> The pwritev2() writer models the streaming workload; it does not show that
> an unchanged Android application already issues RWF_DONTCACHE.
>
> Android remained active with displays off. Each run started after a cache
> reset and at least 120 seconds of cooldown. Throughput and one-second
> kswapd0/global-memory samples cover the write loop.
>
Thanks very much for the update.
> Write-loop throughput was:
What about read?
>
> normal MiB/s dontcache MiB/s
> I/O r1 r2 mean r1 r2 mean change
> 4K 946.28 935.74 941.01 291.36 309.31 300.33 -68.08%
> 8K 1077.05 1105.84 1091.45 477.79 479.79 478.79 -56.13%
> 16K 1126.84 1118.49 1122.67 643.40 652.06 647.73 -42.30%
> 32K 1150.62 1036.33 1093.48 762.24 751.45 756.84 -30.79%
> 64K 1144.80 1163.82 1154.31 852.11 851.19 851.65 -26.22%
> 128K 1166.29 1162.84 1164.57 867.47 865.05 866.26 -25.61%
> 256K 1153.61 1172.78 1163.19 895.53 885.33 890.43 -23.45%
> 512K 1173.61 1197.34 1185.48 903.09 903.01 903.05 -23.82%
> 1M 1126.22 1154.59 1140.41 850.74 894.60 872.67 -23.48%
Seems side-effect, how will this affect userspace applications?
>
> Average kswapd0 CPU and average global Cached were:
>
> I/O kswapd0 CPU, normal/DC Cached MiB, normal/DC
> 4K 18.45% / 0% 4830.15 / 686.56
> 8K 21.60% / 0% 4862.35 / 591.48
> 16K 22.75% / 0% 4905.47 / 625.07
> 32K 22.05% / 0% 4945.82 / 561.59
> 64K 23.46% / 0% 4920.77 / 639.78
> 128K 23.16% / 0% 4971.37 / 693.26
> 256K 23.68% / 0% 4956.93 / 668.60
> 512K 24.25% / 0% 4972.22 / 663.92
> 1M 22.01% / 0% 5001.09 / 705.30
>
> Other global memory means were:
>
> MemAvailable MiB Dirty MiB Writeback MiB
> I/O normal / DC normal / DC normal / DC
> 4K 6513.08 / 6382.31 640.48 / 33.93 37.94 / 0.09
> 8K 6560.77 / 6529.33 690.89 / 43.57 40.84 / 0.54
> 16K 6587.46 / 6519.94 789.16 / 62.67 61.58 / 4.64
> 32K 6571.95 / 6566.74 850.48 / 69.14 67.69 / 9.24
> 64K 6600.64 / 6559.89 856.97 / 134.28 59.60 / 16.19
> 128K 6627.03 / 6465.10 873.68 / 137.57 60.57 / 41.50
> 256K 6615.58 / 6541.09 885.98 / 158.15 61.25 / 29.57
> 512K 6625.52 / 6534.41 900.65 / 139.07 63.65 / 30.35
> 1M 6677.09 / 6539.89 909.70 / 187.56 51.58 / 33.46
>
> Active(file) MiB Inactive(file) MiB
> I/O normal / DC normal / DC
> 4K 279.57 / 264.13 4426.38 / 183.12
> 8K 262.32 / 260.97 4472.62 / 182.19
> 16K 392.09 / 252.95 4392.78 / 195.82
> 32K 254.30 / 248.44 4554.18 / 187.34
> 64K 252.73 / 244.94 4545.40 / 267.28
> 128K 322.02 / 243.95 4530.63 / 298.91
> 256K 245.47 / 240.02 4586.64 / 303.92
> 512K 254.75 / 232.05 4591.17 / 288.27
> 1M 238.88 / 233.64 4638.81 / 341.00
Can we compare the data before/after the patch?
Thanks,
>
> Dontcache left zero target-file pages resident at every size. Normal
> retained about 1.19--1.24 million pages. Normal runs incurred roughly
> 15.6 million kswapd page scans and steals per run, while dontcache recorded
> zero. Direct scan and allocation-stall deltas were zero in both modes.
>
> Changes since the RFC:
>
> - match the stricter proposed bio_in_atomic() eligibility rule;
> - add phone correctness and two-round 64-GiB performance results.
>
> Wenjie Qi (2):
> f2fs: complete dropbehind write bios in safe task context
> f2fs: enable buffered RWF_DONTCACHE
>
> fs/f2fs/data.c | 59 ++++++++++++++++++++++++++++++++++++++++----------
> fs/f2fs/file.c | 2 +-
> 2 files changed, 49 insertions(+), 12 deletions(-)
>
next prev parent reply other threads:[~2026-08-21 1:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 7:14 [PATCH v2 0/2] f2fs: enable buffered RWF_DONTCACHE Wenjie Qi
2026-08-20 7:14 ` [PATCH v2 1/2] f2fs: complete dropbehind write bios in safe task context Wenjie Qi
2026-08-20 11:45 ` Barry Song
2026-08-20 12:18 ` Wenjie Qi
2026-08-20 7:14 ` [PATCH v2 2/2] f2fs: enable buffered RWF_DONTCACHE Wenjie Qi
2026-08-21 1:50 ` Chao Yu [this message]
2026-08-21 2:55 ` [PATCH v2 0/2] " Wenjie Qi
2026-08-24 10:33 ` [PATCH v3 " Wenjie Qi
2026-08-24 10:33 ` [PATCH v3 1/2] f2fs: complete dropbehind write bios in safe task context Wenjie Qi
2026-08-25 5:48 ` Christoph Hellwig
2026-08-25 6:43 ` Wenjie Qi
2026-08-24 10:33 ` [PATCH v3 2/2] f2fs: enable buffered RWF_DONTCACHE Wenjie Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15a3ea00-8f50-4673-b445-1c83b1369ae8@kernel.org \
--to=chao@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=qiwenjie@xiaomi.com \
--cc=qwjhust@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox