From: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
To: linux-xfs@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org,
"Darrick J . Wong" <djwong@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Christoph Hellwig <hch@infradead.org>,
Brian Foster <bfoster@redhat.com>,
Andreas Gruenbacher <agruenba@redhat.com>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
Subject: [PATCHv11 0/8] iomap: Add support for per-block dirty state to improve write performance
Date: Sat, 1 Jul 2023 13:04:33 +0530 [thread overview]
Message-ID: <cover.1688188958.git.ritesh.list@gmail.com> (raw)
Hello All,
Please find PATCHv11 which adds per-block dirty tracking to iomap.
As discussed earlier this is required to improve write performance and reduce
write amplification for cases where either blocksize is less than pagesize (such
as Power platform with 64k pagesize) or when we have a large folio (such as xfs
which currently supports large folio).
Thanks everyone for helping with reviews and suggestions.
v10 -> v11:
===========
1. Dropped iomap_block_state enum. Thereby automatically addressing variables
names like first_blk etc. in bitmap handling functions.
Testing of v11:
===============
1. I have done fstests testing of v11 on my setup for x86 (1k & 4k bs),
arm (4k bs) and Power (4k bs) with xfstests. I haven't found any new
failures as such in my testing so far with xfstests.
2. I have also done some random read/write testing using fio & haven't
observed any performance issues in my testing so far.
<Perf data copy paste from previous version>
=============================================
Performance testing of below fio workload reveals ~16x performance
improvement using nvme with XFS (4k blocksize) on Power (64K pagesize)
FIO reported write bw scores improved from around ~28 MBps to ~452 MBps.
1. <test_randwrite.fio>
[global]
ioengine=psync
rw=randwrite
overwrite=1
pre_read=1
direct=0
bs=4k
size=1G
dir=./
numjobs=8
fdatasync=1
runtime=60
iodepth=64
group_reporting=1
[fio-run]
2. Also our internal performance team reported that this patch improves
their database workload performance by around ~83% (with XFS on Power)
Ritesh Harjani (IBM) (8):
iomap: Rename iomap_page to iomap_folio_state and others
iomap: Drop ifs argument from iomap_set_range_uptodate()
iomap: Add some uptodate state handling helpers for ifs state bitmap
iomap: Fix possible overflow condition in iomap_write_delalloc_scan
iomap: Use iomap_punch_t typedef
iomap: Refactor iomap_write_delalloc_punch() function out
iomap: Allocate ifs in ->write_begin() early
iomap: Add per-block dirty state tracking to improve performance
fs/gfs2/aops.c | 2 +-
fs/iomap/buffered-io.c | 402 ++++++++++++++++++++++++++++-------------
fs/xfs/xfs_aops.c | 2 +-
fs/zonefs/file.c | 2 +-
include/linux/iomap.h | 1 +
5 files changed, 281 insertions(+), 128 deletions(-)
--
2.40.1
next reply other threads:[~2023-07-01 7:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-01 7:34 Ritesh Harjani (IBM) [this message]
2023-07-01 7:34 ` [PATCHv11 1/8] iomap: Rename iomap_page to iomap_folio_state and others Ritesh Harjani (IBM)
2023-07-13 4:31 ` Darrick J. Wong
2023-07-01 7:34 ` [PATCHv11 2/8] iomap: Drop ifs argument from iomap_set_range_uptodate() Ritesh Harjani (IBM)
2023-07-13 4:31 ` Darrick J. Wong
2023-07-01 7:34 ` [PATCHv11 3/8] iomap: Add some uptodate state handling helpers for ifs state bitmap Ritesh Harjani (IBM)
2023-07-13 4:32 ` Darrick J. Wong
2023-07-01 7:34 ` [PATCHv11 4/8] iomap: Fix possible overflow condition in iomap_write_delalloc_scan Ritesh Harjani (IBM)
2023-07-13 4:33 ` Darrick J. Wong
2023-07-01 7:34 ` [PATCHv11 5/8] iomap: Use iomap_punch_t typedef Ritesh Harjani (IBM)
2023-07-13 4:33 ` Darrick J. Wong
2023-07-01 7:34 ` [PATCHv11 6/8] iomap: Refactor iomap_write_delalloc_punch() function out Ritesh Harjani (IBM)
2023-07-01 7:34 ` [PATCHv11 7/8] iomap: Allocate ifs in ->write_begin() early Ritesh Harjani (IBM)
2023-07-01 7:34 ` [PATCHv11 8/8] iomap: Add per-block dirty state tracking to improve performance Ritesh Harjani (IBM)
2023-07-06 14:46 ` Ritesh Harjani
2023-07-06 17:42 ` Matthew Wilcox
2023-07-06 22:16 ` Dave Chinner
2023-07-06 23:54 ` Matthew Wilcox
2023-07-10 18:19 ` Ritesh Harjani
2023-07-13 4:38 ` Darrick J. Wong
2023-07-13 5:27 ` Ritesh Harjani
2023-07-13 4:36 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1688188958.git.ritesh.list@gmail.com \
--to=ritesh.list@gmail.com \
--cc=agruenba@redhat.com \
--cc=bfoster@redhat.com \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).