From: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
To: linux-xfs@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>,
"Darrick J . Wong" <djwong@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
Subject: [RFC 0/2] iomap: Add support for subpage dirty state tracking to improve write performance
Date: Fri, 28 Oct 2022 10:00:31 +0530 [thread overview]
Message-ID: <cover.1666928993.git.ritesh.list@gmail.com> (raw)
Hello,
Please find the RFC patchset which adds support for iomap subpage dirty state
tracking which improves write performance and should reduce the write amplification
on platforms with smaller filesystem blocksize compared to pagesize.
E.g. On Power with 64k default pagesize and with 4k XFS filesystem blocksize.
I have done some minimal fsstress and fstests testing using this patchset
and haven't noticed any issues as such. Posting this RFC to get some
initial comments/thoughts on the patch.
I will run full fstests with XFS if this RFC looks good.
From review perspective, it will be helpful if one can also review the error
handling path. I wasn't sure on whether we need to clear the dirty state bitmap
of blocks within a folio or not in iomap_writepage_map(). I don't clear that,
since AFAIU, the error in that function is due to failed ->map_blocks() function
which has nothing to do with tracking subpage dirty state of a block within
folio. But please let me know your thoughts on this or other error handling path.
Performance results
======================
1. Performance testing of below fio workload reveals ~16x performance
improvement on nvme with XFS (4k blocksize) on Power (64K pagesize)
FIO reported write bw scores, improved from ~28 MBps to ~452 MBps.
<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 there
database workload performance by around ~83% (with XFS on Power)
Note: I did come across an older RFC around the same logic to track subpage
dirty tracking here [1]. But it seems no one pursued it after iomap received
folio changes update.
[1]: https://lore.kernel.org/linux-xfs/20200821123306.1658495-1-yukuai3@huawei.com/#t
Ritesh Harjani (IBM) (2):
iomap: Change uptodate variable name to state
iomap: Support subpage size dirty tracking to improve write performance
fs/iomap/buffered-io.c | 79 ++++++++++++++++++++++++++++++++++--------
1 file changed, 64 insertions(+), 15 deletions(-)
--
2.37.3
next reply other threads:[~2022-10-28 4:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-28 4:30 Ritesh Harjani (IBM) [this message]
2022-10-28 4:30 ` [RFC 1/2] iomap: Change uptodate variable name to state Ritesh Harjani (IBM)
2022-10-28 16:31 ` Darrick J. Wong
2022-10-29 3:09 ` Ritesh Harjani (IBM)
2022-10-28 4:30 ` [RFC 2/2] iomap: Support subpage size dirty tracking to improve write performance Ritesh Harjani (IBM)
2022-10-28 12:42 ` Matthew Wilcox
2022-10-29 3:05 ` Ritesh Harjani (IBM)
2022-10-28 17:01 ` Darrick J. Wong
2022-10-28 18:15 ` Matthew Wilcox
2022-10-29 3:25 ` Ritesh Harjani (IBM)
2022-10-28 21:04 ` Dave Chinner
2022-10-30 3:27 ` Ritesh Harjani (IBM)
2022-10-30 22:31 ` Dave Chinner
2022-10-31 3:43 ` Matthew Wilcox
2022-10-31 7:08 ` Dave Chinner
2022-10-31 10:27 ` Matthew Wilcox
2022-11-02 8:57 ` Christoph Hellwig
2022-11-03 0:38 ` Dave Chinner
2022-11-02 9:03 ` Christoph Hellwig
2022-11-02 17:35 ` Darrick J. Wong
2022-11-04 7:27 ` Christoph Hellwig
2022-11-04 14:15 ` Ritesh Harjani (IBM)
2022-11-03 14:51 ` David Howells
2022-11-04 7:30 ` Christoph Hellwig
2022-11-07 13:03 ` David Howells
2022-11-04 11:28 ` Ritesh Harjani (IBM)
2022-11-03 14:12 ` David Howells
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.1666928993.git.ritesh.list@gmail.com \
--to=ritesh.list@gmail.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).