kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity

Create large folios in iomap buffered write path

Browse source 
Commit ebb7fb1557 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
 
 https://lore.kernel.org/linux-xfs/20230508172406.1CF3.409509F4@e16-tech.com/
 
 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.
 
 Creating large folios in the buffered write path is also the right
 thing to do.  It's a project that has been on the back burner for years,
 it just hasn't been important enough to do before now.
 -----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCgAdFiEEejHryeLBw/spnjHrDpNsjXcpgj4FAmS+/8YACgkQDpNsjXcp
 gj6jwgf/YpI9mbo63D55QRpMVhvej10aGxZj497IJW5bEqh5cRX0x+kUZkMOW36a
 iBB4iiTT+Gl6Z7eJ89W4J7Es48k8hHaprh1WGjlI0zHmBhXvNGHKSk7Egno1BS2v
 23YEzBGOdA6dlhDLA9PNIiV5berwTxyNbdv/PadKxDcWy65UvwZ8FCQfli9E0CP6
 aeG8PU8RybagYUQYQuCU7TgcCJNpthJHmYBy+iJEZy/9JI0klYvHUaLo6hl1wgXw
 Cthc63C4lYtCY/koHFaD8W24RYAZQF+BMTE6oL6X+tA70fRL7ozCGtu4Mjk55kmJ
 yNkVqw2ImTuwLRxfxPyEp23Iwz9alA==
 =WE72
 -----END PGP SIGNATURE-----

Merge tag 'large-folio-writes' of git://git.infradead.org/users/willy/pagecache into iomap-6.6-merge

Create large folios in iomap buffered write path

Commit ebb7fb1557 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

https://lore.kernel.org/linux-xfs/20230508172406.1CF3.409509F4@e16-tech.com/

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.

Creating large folios in the buffered write path is also the right
thing to do.  It's a project that has been on the back burner for years,
it just hasn't been important enough to do before now.

* tag 'large-folio-writes' of git://git.infradead.org/users/willy/pagecache:
  iomap: Copy larger chunks from userspace
  iomap: Create large folios in the buffered write path
  filemap: Allow __filemap_get_folio to allocate large folios
  filemap: Add fgf_t typedef
  iomap: Remove unnecessary test from iomap_release_folio()
  doc: Correct the description of ->release_folio
  iomap: Remove large folio handling in iomap_invalidate_folio()
  iov_iter: Add copy_folio_from_iter_atomic()
  iov_iter: Handle compound highmem pages in copy_page_from_iter_atomic()
  iov_iter: Map the page later in copy_page_from_iter_atomic()

[djwong: yay amortizations!]
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
This commit is contained in:
Darrick J. Wong 2023-07-24 16:12:29 -07:00
commit d42bd17c6a
13 changed files with 187 additions and 110 deletions
Download patch file Download diff file Expand all files Collapse all files