]> www.infradead.org Git - users/jedix/linux-maple.git/commit
iomap: elide flush from partial eof zero range
authorBrian Foster <bfoster@redhat.com>
Fri, 15 Nov 2024 20:01:55 +0000 (15:01 -0500)
committerChristian Brauner <brauner@kernel.org>
Thu, 21 Nov 2024 08:35:25 +0000 (09:35 +0100)
commitfde4c4c3ec1c1590eb09f97f9525fa7dd8df8343
tree95a57b4e1f8042d7459ea08da93cb49700f390d5
parent889ac75787cbeb129df7faf917ce7d53a32ea696
iomap: elide flush from partial eof zero range

iomap zero range flushes pagecache in certain situations to
determine which parts of the range might require zeroing if dirty
data is present in pagecache. The kernel robot recently reported a
regression associated with this flushing in the following stress-ng
workload on XFS:

stress-ng --timeout 60 --times --verify --metrics --no-rand-seed --metamix 64

This workload involves repeated small, strided, extending writes. On
XFS, this produces a pattern of post-eof speculative preallocation,
conversion of preallocation from delalloc to unwritten, dirtying
pagecache over newly unwritten blocks, and then rinse and repeat
from the new EOF. This leads to repetitive flushing of the EOF folio
via the zero range call XFS uses for writes that start beyond
current EOF.

To mitigate this problem, special case EOF block zeroing to prefer
zeroing the folio over a flush when the EOF folio is already dirty.
To do this, split out and open code handling of an unaligned start
offset. This brings most of the performance back by avoiding flushes
on zero range calls via write and truncate extension operations. The
flush doesn't occur in these situations because the entire range is
post-eof and therefore the folio that overlaps EOF is the only one
in the range.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Link: https://lore.kernel.org/r/20241115200155.593665-4-bfoster@redhat.com
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner <brauner@kernel.org>
fs/iomap/buffered-io.c