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>,
Andreas Gruenbacher <agruenba@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Christoph Hellwig <hch@infradead.org>,
Brian Foster <bfoster@redhat.com>,
Ojaswin Mujoo <ojaswin@linux.ibm.com>,
Disha Goel <disgoel@linux.ibm.com>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
Subject: [PATCHv10 0/8] iomap: Add support for per-block dirty state to improve write performance
Date: Mon, 19 Jun 2023 07:58:43 +0530 [thread overview]
Message-ID: <cover.1687140389.git.ritesh.list@gmail.com> (raw)
Hello All,
Please find PATCHv10 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).
v9 -> v10:
===========
1. Mostly function renames from iomap_ifs_** to ifs_** (patch-1)
2. Addressed review comments from Darrick & Andreas
3. Added 2 suggested by patches from Matthew (patch-4 & patch-5)
4. Defined a new separate function for iomap_write_delalloc_ifs_punch() in
Patch-8
Note: since v10 mainly had function name changes in existing patches (which
already had reviewed-by), hence I have kept the Reviewed-by from previous
reviewers as is.
Testing of v10:
===============
I have done some weekend long testing of v10 on my setup for x86 (1k & 4k bs),
arm (4k bs, 64k ps) and Power (4k bs) with xfstests. I haven't found any new
failures as such in my testing so far with xfstests.
v7/v8 -> v9
============
1. Splitted the renaming & refactoring changes into different patchsets.
(Patch-1 & Patch-2)
2. Addressed review comments from everyone in v9.
3. Fixed a punch-out bug pointed out by Darrick in Patch-6.
4. Included iomap_ifs_calc_range() function suggested by Christoph in Patch-6.
Testing
=========
I have tested v9 on:-
- Power with 4k blocksize -g auto
- x86 with 1k and 1k_adv with -g auto
- arm64 with 4k blocksize and 64k pagesize with 4k quick
- also tested gfs2 with minimal local config (-O -b 1024 -p lock_nolock)
- unit tested failed punch-out operation with "-f" support to pwrite in
xfs_io.
I haven't observed any new testcase failures in any of my testing so far.
Thanks everyone for helping with reviews and suggestions.
Please do let me know if there are any further review comments on this one.
<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 | 418 +++++++++++++++++++++++++++++------------
fs/xfs/xfs_aops.c | 2 +-
fs/zonefs/file.c | 2 +-
include/linux/iomap.h | 1 +
5 files changed, 298 insertions(+), 127 deletions(-)
--
2.40.1
next reply other threads:[~2023-06-19 2:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-19 2:28 Ritesh Harjani (IBM) [this message]
2023-06-19 2:28 ` [PATCHv10 1/8] iomap: Rename iomap_page to iomap_folio_state and others Ritesh Harjani (IBM)
2023-06-19 2:28 ` [PATCHv10 2/8] iomap: Drop ifs argument from iomap_set_range_uptodate() Ritesh Harjani (IBM)
2023-06-19 2:28 ` [PATCHv10 3/8] iomap: Add some uptodate state handling helpers for ifs state bitmap Ritesh Harjani (IBM)
2023-06-19 2:28 ` [PATCHv10 4/8] iomap: Fix possible overflow condition in iomap_write_delalloc_scan Ritesh Harjani (IBM)
2023-06-19 2:28 ` [PATCHv10 5/8] iomap: Use iomap_punch_t typedef Ritesh Harjani (IBM)
2023-06-19 2:28 ` [PATCHv10 6/8] iomap: Refactor iomap_write_delalloc_punch() function out Ritesh Harjani (IBM)
2023-06-19 2:28 ` [PATCHv10 7/8] iomap: Allocate ifs in ->write_begin() early Ritesh Harjani (IBM)
2023-06-19 2:28 ` [PATCHv10 8/8] iomap: Add per-block dirty state tracking to improve performance Ritesh Harjani (IBM)
2023-06-19 12:43 ` Andreas Gruenbacher
2023-06-19 16:55 ` Ritesh Harjani
2023-06-19 14:26 ` Matthew Wilcox
2023-06-19 16:25 ` Ritesh Harjani
2023-06-19 16:54 ` Matthew Wilcox
2023-06-19 17:29 ` Ritesh Harjani
2023-06-20 5:01 ` Darrick J. Wong
2023-06-20 5:58 ` Ritesh Harjani
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.1687140389.git.ritesh.list@gmail.com \
--to=ritesh.list@gmail.com \
--cc=agruenba@redhat.com \
--cc=bfoster@redhat.com \
--cc=disgoel@linux.ibm.com \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--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).