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()
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
