linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


             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).