Resend: original patch was misspelling
the [email protected] address.
No code changes.
This RFC series enable buffered read/write paths large folio support
with F2FS-specific extended iomap, combined with some other preparation
work for large folio integration.
Because this is my first time to send a patch series to the kernel
mailing list,
I might have missed some conventions.
The patch passes checkpatch.pl with no errors,
but a few warnings remain.
I wasn't sure about the best way to address them,
so I would appreciate your guidance.
I am happy to fix them if needed.
Motivations:
* **Why iomap**:
* F2FS couples pages directly to BIOs without a per-block tracking
struct like buffer-head or sub-page.
A naive large-folio port would cause:
* Write-amplification.
* Premature folio_end_read() / folio_end_writeback()
when multi sub-ranges of a large folio are in io concurrently.
Above issues has already been handled cleanly by iomap_folio_state.
* Original buffered write path unlocks a folio halfway,causes status
recheck for large folios carried with iomap_folio_state
or partially trucnated folio tricky.iomap handles all locking
unlocking operations automatically.
* **Why extends iomap**
* F2FS stores its flags in the folio's private field,
which conflicts with iomap_folio_state.
* To resolve this, we designed f2fs_iomap_folio_state,
compatible with iomap_folio_state's layout while extending
its flexible state array for F2FS private flags.
* We store a magic number in read_bytes_pending to distinguish
whether a folio uses the original or F2FS's iomap_folio_state.
It's chosen because it remains 0 after readahead completes.
Implementation notes:
* New Kconfig: `CONFIG_F2FS_IOMAP_FOLIO_STATE`; when off,falls back
to the legacy buffered io path.
Limitations
* Don't support BLOCK_SIZE > PAGE_SIZE now.
* Don't support large folios for encrypted and fsverity files.
* Page writeback and compressed files large folios support is still WIP.
Why RFC:
* Need review and potential improvement on
`f2fs_iomap_folio_state` design and implementation.
* Limited test coverage so far.Any extra testing is highly appreciated.
* Two runtime issues remain (see below).
Performance Testing:
* Platform: x86-64 laptop (PCIe 4.0 NVMe) -> qemu-arm64 VM, 4 GiB RAM
* Kernel: gcc-13.2, defconfig + `CONFIG_F2FS_IOMAP_FOLIO_STATE=y`
fio 3.35, `ioengine=psync`, `size=1G`, `numjobs=1`
Read throughput (MiB/s):
--- Kernel: iomap_v1 file type: normal ---
Block Size (bs) | Avg. Bandwidth (MiB/s) | Avg. IOPS
---------------------+------------------------------+-----------------
100M | 2809.60 | 27.50
10M | 3184.60 | 317.90
128k | 1376.20 | 11000.80
1G | 1954.70 | 1.20
1M | 2717.00 | 2716.70
4k | 616.50 | 157800.00
--- Kernel: vanilla file type: normal ---
Block Size (bs) | Avg. Bandwidth (MiB/s) | Avg. IOPS
---------------------+------------------------------+-----------------
100M | 994.60 | 9.60
10M | 986.50 | 98.10
128k | 693.80 | 5550.90
1G | 816.90 | 0.00
1M | 968.90 | 968.40
4k | 429.80 | 109990.00
--- Kernel: iomap_v1 file type: hole ---
Block Size (bs) | Avg. Bandwidth (MiB/s) | Avg. IOPS
---------------------+------------------------------+-----------------
100M | 1825.60 | 17.70
10M | 1989.24 | 198.42
1G | 1312.80 | 0.90
1M | 2326.02 | 2325.42
4k | 799.40 | 204700.00
--- Kernel: vanilla file type: hole ---
Block Size (bs) | Avg. Bandwidth (MiB/s) | Avg. IOPS
---------------------+------------------------------+-----------------
100M | 708.90 | 6.50
10M | 735.00 | 73.10
128k | 786.70 | 6292.20
1G | 613.20 | 0.00
1M | 764.50 | 764.25
4k | 478.80 | 122400.00
Sparse-file numbers on qemu look skewed; further bare-metal tests planned.
Write benchmarks are currently blocked by the issues below.
Known issues (help appreciated)
**Write throttling stalls**
```sh
dd if=/dev/zero of=test.img bs=1G count=1 conv=fsync
```
Write speed decays; task spins in `iomap_write_iter`
->`balance_dirty_pages_ratelimited_flags`.
**fsync dead-lock**
```sh
fio --rw=write --bs=4K --fsync=1 --size=1G --ioengine=psync ???
```
Task Hangs in `f2fs_issue_flush`->'submit_bio_wait'
Full traces will be posted in a follow-up.
Nanzhe Zhao (9):
f2fs: Introduce f2fs_iomap_folio_state
f2fs: Integrate f2fs_iomap_folio_state into f2fs page private helpers
f2fs: Using `folio_detach_f2fs_private` in invalidate and release
folio
f2fs: Convert outplace write path page private funcions to folio
private functions.
f2fs:Refactor `f2fs_is_compressed_page` to `f2fs_is_compressed_folio`
f2fs: Extend f2fs_io_info to support sub-folio ranges
f2fs:Make GC aware of large folios
f2fs: Introduce F2FS_GET_BLOCK_IOMAP and map_blocks he lpers
f2fs: Enable buffered read/write path large folios support for normal
and atomic file with iomap
fs/f2fs/Kconfig | 10 ++
fs/f2fs/Makefile | 1 +
fs/f2fs/compress.c | 11 +-
fs/f2fs/data.c | 389 ++++++++++++++++++++++++++++++++++++------
fs/f2fs/f2fs.h | 412 ++++++++++++++++++++++++++++++++++-----------
fs/f2fs/f2fs_ifs.c | 221 ++++++++++++++++++++++++
fs/f2fs/f2fs_ifs.h | 79 +++++++++
fs/f2fs/file.c | 33 +++-
fs/f2fs/gc.c | 37 ++--
fs/f2fs/inline.c | 15 +-
fs/f2fs/inode.c | 27 +++
fs/f2fs/namei.c | 7 +
fs/f2fs/segment.c | 2 +-
fs/f2fs/super.c | 3 +
14 files changed, 1082 insertions(+), 165 deletions(-)
create mode 100644 fs/f2fs/f2fs_ifs.c
create mode 100644 fs/f2fs/f2fs_ifs.h
base-commit: b45116aef78ff0059abf563b339e62a734487a50
--
2.34.1
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
