Hi,
> Commit ebb7fb1557b1 limited the length of ioend chains to 4096 entries
> to improve worst-case latency. Unfortunately, this had the effect of
> limiting the performance of:
>
> fio -name write-bandwidth -rw=write -bs=1024Ki -size=32Gi -runtime=30 \
> -iodepth 1 -ioengine sync -zero_buffers=1 -direct=0 -end_fsync=1 \
> -numjobs=4 -directory=/mnt/test
>
> The problem ends up being lock contention on the i_pages spinlock as we
> clear the writeback bit on each folio (and propagate that up through
> the tree). By using larger folios, we decrease the number of folios
> to be processed by a factor of 256 for this benchmark, eliminating the
> lock contention.
>
> It's also the right thing to do. This is a project that has been on
> the back burner for years, it just hasn't been important enough to do
> before now.
>
> I think it's probably best if this goes through the iomap tree since
> the changes outside iomap are either to the page cache or they're
> trivial.
>
> v2:
> - Fix misplaced semicolon
> - Rename fgp_order to fgp_set_order
> - Rename FGP_ORDER to FGP_GET_ORDER
> - Add fgp_t
> - Update the documentation for ->release_folio
> - Fix iomap_invalidate_folio()
> - Update iomap_release_folio()
It works well based on 6.4-rc4 here.
fio write bandwidth: about 8000MiB/s
And I tried to backport it to 6.1.y, it works well too.
1) 8 patches are selected as depency.
d7b64041164c :Dave Chinner: iomap: write iomap validity checks
7a70a5085ed0 :Andreas Gruenbacher: iomap: Add __iomap_put_folio helper
80baab88bb93 :Andreas Gruenbacher: iomap/gfs2: Unlock and put folio in page_done handler
40405dddd98a :Andreas Gruenbacher: iomap: Rename page_done handler to put_folio
98321b5139f9 :Andreas Gruenbacher: iomap: Add iomap_get_folio helper
9060bc4d3aca :Andreas Gruenbacher: iomap/gfs2: Get page in page_prepare handler
07c22b56685d :Andreas Gruenbacher: iomap: Add __iomap_get_folio helper
c82abc239464 :Andreas Gruenbacher: iomap: Rename page_prepare handler to get_folio
2) patch 4/5/6 are rebased (see attachment files)
better backport are welcome.
Best Regards
Wang Yugui (wangyugui@xxxxxxxxxxxx)
2023/06/04
> Matthew Wilcox (Oracle) (7):
> iomap: Remove large folio handling in iomap_invalidate_folio()
> doc: Correct the description of ->release_folio
> iomap: Remove unnecessary test from iomap_release_folio()
> filemap: Add fgp_t typedef
> filemap: Allow __filemap_get_folio to allocate large folios
> iomap: Create large folios in the buffered write path
> iomap: Copy larger chunks from userspace
>
> Documentation/filesystems/locking.rst | 14 ++++--
> fs/btrfs/file.c | 6 +--
> fs/f2fs/compress.c | 2 +-
> fs/f2fs/f2fs.h | 2 +-
> fs/gfs2/bmap.c | 2 +-
> fs/iomap/buffered-io.c | 43 ++++++++--------
> include/linux/iomap.h | 2 +-
> include/linux/pagemap.h | 71 ++++++++++++++++++++++-----
> mm/filemap.c | 61 ++++++++++++-----------
> mm/folio-compat.c | 2 +-
> mm/readahead.c | 13 -----
> 11 files changed, 130 insertions(+), 88 deletions(-)
>
> --
> 2.39.2
Attachment:
0006-iomap-Create-large-folios-in-the-buffered-write-path.patch
Description: Binary data
Attachment:
0004-filemap-Add-fgp_t-typedef.patch
Description: Binary data
Attachment:
0005-filemap-Allow-__filemap_get_folio-to-allocate-large-.patch
Description: Binary data
Attachment:
0006-iomap-Create-large-folios-in-the-buffered-write-path.patch
Description: Binary data
