Re: [f2fs-dev] [RFC PATCH v2 00/10] f2fs: support & optimize large folios for writable files

Chao Yu via Linux-f2fs-devel <[email protected]>
Newsgroups net.sourceforge.lists.linux-f2fs-devel,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
Nanzhe,

I can see a lots of testcases failure in xfstests, can you please address all
of them?

On 6/23/26 00:08, Nanzhe Zhao wrote:
> From: Nanzhe Zhao <[email protected]>
> 
> Make some clean up based on v1, and support minimum folio orders 
> beyond zero.
> 
> This RFC series supports large folios for most readable/writable files in
> buffered I/O paths, including normal files, block-layer encrypted files,
> and atomic files. Compressed files are still excluded.
> 
> Atomic files need explicit support here because Android enables atomic
> writes through ioctls, which mark the inode as an atomic file
> (FI_ATOMIC_FILE). Once large-folio mapping is enabled for such a file,
> the atomic buffered write path also needs to handle large folios
> correctly.
> 
> In the write path, allocating f2fs_folio_state for large folios starts
> to conflict with f2fs page-private flags. This RFC series extends
> f2fs_folio_state so that it can also store f2fs private flags, and
> updates the existing PAGE_PRIVATE helpers to work correctly with
> f2fs_folio_state.
> 
> In addition, fio results with max large-folio order set to 2 showed
> that 4K read/write performance did not improve much.
> Analysis showed that one important reason was the extra spinlock traffic
> from incrementing read_pages_pending once per 4K subpage.
> This RFC series therefore adds two optimizations to
> f2fs_read_data_large_folio:
> 
> 1. batch read_pages_pending updates by the mapped block count instead of
>    incrementing it once per 4K subpage;
> 
> 2. skip f2fs_folio_state allocation when a single block mapping / BIO
>    covers the whole folio, because folio_end_read() can complete such a
>    folio without extra per-folio state.
> 
> In the benchmark tables below, "skip=1" means enabling the second
> optimization above, i.e. skipping f2fs_folio_state allocation for the
> whole-folio-in-one-bio case.
> The "batch" optimization refers to updating read_pages_pending in
> and add to bio in larger chunks instead of once per subpage.
> 
> Test environment:
> - Device: Pixel 6 (device1A, 1A071FDF600053)
> - Filesystem: f2fs on dm-49, inlinecrypt enabled
> - File size: 256MB
> - Repetitions: 10
> - Prepare: end_fsync + sync + drop_caches
> - Fio: psync, direct=0, iodepth=1
> - Max folio order: 2
> 
> Table 1: HOLE_READ (10 repeats)
> ------------------------------------------------------------
> All bandwidth numbers are in MiB/s. Non-baseline entries show the
> absolute value followed by the percentage delta relative to the
> order=0 baseline in parentheses.
> 
> | bs  | order=0 | order=2 |
> |-----|---------|---------|
> | 4k  | 469.6   | 521.9 (+11.1%) |
> | 64k | 668.1   | 852.4 (+27.6%) |
> | 1M  | 653.0   | 867.2 (+32.8%) |
> 
> Table 2: DATA_READ (10 repeats)
> ----------------------------------------
> | bs  | order=0 | batch=0 | batch=1,skip=0 | batch=1,skip=1 |
> |-----|---------|---------|----------------|----------------|
> | 4k  | 441.6   | 456.5 (+3.4%) | 499.7 (+13.2%) | 544.4 (+23.3%) |
> | 64k | 632.8   | 697.0 (+10.1%) | 837.8 (+32.4%) | 990.9 (+56.6%) |
> | 1M  | 601.5   | 733.0 (+21.9%) | 927.5 (+54.2%) | 963.4 (+60.2%) |
> 
> Table 3: WRITE (10 reps)
> ----------------------------------------------------------
> O = overwrite (N = new write, Y = overwrite)
> S = sync / fsync (Y = fsync enabled, N = no fsync)
> W = writeback (Y = background writeback, N = no writeback)
> 
> | O,S,W | bs  | order=0 | order=2 |
> |-------|-----|---------|---------|
> | N,N,Y | 4k  | 263.4   | 286.3 (+8.7%) |
> | N,N,Y | 64k | 683.5   | 1199.6 (+75.5%) |
> | N,N,Y | 1M  | 767.4   | 1383.8 (+80.3%) |
> | N,Y,N | 4k  | 10.8    | 9.1 (-15.7%) |
> | N,Y,N | 64k | 69.3    | 50.3 (-27.4%) |
> | N,Y,N | 1M  | 103.5   | 157.8 (+52.5%) |
> | Y,N,Y | 4k  | 301.6   | 344.1 (+14.1%) |
> | Y,N,Y | 64k | 691.3   | 865.9 (+25.3%) |
> | Y,N,Y | 1M  | 742.3   | 969.2 (+30.6%) |
> | Y,Y,N | 4k  | 9.5     | 17.1 (+80.0%) |
> | Y,Y,N | 64k | 43.5    | 108.2 (+148.7%) |
> | Y,Y,N | 1M  | 140.9   | 146.6 (+4.0%) |
> 
> Nanzhe (9):
>   f2fs: extend folio state for large folio write path
>   f2fs: carry subpage offset and count in write IO
>   f2fs: support regular file buffered writes on large folios
>   f2fs: support atomic file large folios buffered write
>   f2fs: support large folio writeback
>   f2fs: prepare mmap write faults for large folios
>   f2fs: make GC migration large-folio aware
>   f2fs: allow large folio support to writeable files
>   f2fs: optimize small block size large folio read
> 
>  fs/f2fs/compress.c |    2 +
>  fs/f2fs/data.c     | 1015 +++++++++++++++++++++++++++++++++++++++-----
>  fs/f2fs/f2fs.h     |   75 +++-
>  fs/f2fs/file.c     |   81 ++--
>  fs/f2fs/gc.c       |   30 +-
>  fs/f2fs/inode.c    |    6 +-
>  fs/f2fs/segment.c  |    4 +-
>  7 files changed, 1064 insertions(+), 149 deletions(-)
> 



_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.