The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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(-)
> 


  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