From: Dave Chinner <david@fromorbit.com>
To: Zhang Yi <yi.zhang@huaweicloud.com>
Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, djwong@kernel.org,
hch@infradead.org, brauner@kernel.org, jack@suse.cz,
willy@infradead.org, yi.zhang@huawei.com,
chengzhihao1@huawei.com, yukuai3@huawei.com
Subject: Re: [PATCH v2 0/6] iomap: some minor non-critical fixes and improvements when block size < folio size
Date: Wed, 14 Aug 2024 11:49:15 +1000 [thread overview]
Message-ID: <ZrwNG9ftNaV4AJDd@dread.disaster.area> (raw)
In-Reply-To: <20240812121159.3775074-1-yi.zhang@huaweicloud.com>
On Mon, Aug 12, 2024 at 08:11:53PM +0800, Zhang Yi wrote:
> From: Zhang Yi <yi.zhang@huawei.com>
>
> Changes since v1:
> - Patch 5 fix a stale data exposure problem pointed out by Willy, drop
> the setting of uptodate bits after zeroing out unaligned range.
> - As Dave suggested, in order to prevent increasing the complexity of
> maintain the state_lock, don't just drop all the state_lock in the
> buffered write path, patch 6 introduce a new helper to set uptodate
> bit and dirty bits together under the state_lock, reduce one time of
> locking per write, the benefits of performance optimization do not
> change too much.
It's helpful to provide a lore link to the previous version so that
reviewers don't have to go looking for it themselves to remind them
of what was discussed last time.
https://lore.kernel.org/linux-xfs/20240731091305.2896873-1-yi.zhang@huaweicloud.com/T/
> This series contains some minor non-critical fixes and performance
> improvements on the filesystem with block size < folio size.
>
> The first 4 patches fix the handling of setting and clearing folio ifs
> dirty bits when mark the folio dirty and when invalidat the folio.
> Although none of these code mistakes caused a real problem now, it's
> still deserve a fix to correct the behavior.
>
> The second 2 patches drop the unnecessary state_lock in ifs when setting
> and clearing dirty/uptodate bits in the buffered write path, it could
> improve some (~8% on my machine) buffer write performance. I tested it
> through UnixBench on my x86_64 (Xeon Gold 6151) and arm64 (Kunpeng-920)
> virtual machine with 50GB ramdisk and xfs filesystem, the results shows
> below.
>
> UnixBench test cmd:
> ./Run -i 1 -c 1 fstime-w
>
> Before:
> x86 File Write 1024 bufsize 2000 maxblocks 524708.0 KBps
> arm64 File Write 1024 bufsize 2000 maxblocks 801965.0 KBps
>
> After:
> x86 File Write 1024 bufsize 2000 maxblocks 569218.0 KBps
> arm64 File Write 1024 bufsize 2000 maxblocks 871605.0 KBps
Those are the same performance numbers as you posted for the
previous version of the patch. How does this new version perform
given that it's a complete rework of the optimisation? It's
important to know if the changes made actually provided the benefit
we expected them to make....
i.e. this is the sort of table of results I'd like to see provided:
platform base v1 v2
x86 524708.0 569218.0 ????
arm64 801965.0 871605.0 ????
-Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2024-08-14 1:49 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-12 12:11 [PATCH v2 0/6] iomap: some minor non-critical fixes and improvements when block size < folio size Zhang Yi
2024-08-12 12:11 ` [PATCH v2 1/6] iomap: correct the range of a partial dirty clear Zhang Yi
2024-08-12 16:33 ` Darrick J. Wong
2024-08-13 2:14 ` Zhang Yi
2024-08-14 1:53 ` Dave Chinner
2024-08-12 12:11 ` [PATCH v2 2/6] iomap: support invalidating partial folios Zhang Yi
2024-08-12 16:55 ` Darrick J. Wong
2024-08-12 12:11 ` [PATCH v2 3/6] iomap: advance the ifs allocation if we have more than one blocks per folio Zhang Yi
2024-08-12 12:47 ` yangerkun
2024-08-13 2:21 ` Zhang Yi
2024-08-14 5:32 ` Christoph Hellwig
2024-08-14 7:08 ` Zhang Yi
2024-08-15 6:00 ` Christoph Hellwig
2024-08-16 1:44 ` Zhang Yi
2024-08-17 4:27 ` Zhang Yi
2024-08-17 4:42 ` Matthew Wilcox
2024-08-17 6:16 ` Zhang Yi
2024-08-12 12:11 ` [PATCH v2 4/6] iomap: correct the dirty length in page mkwrite Zhang Yi
2024-08-12 16:45 ` Darrick J. Wong
2024-08-13 2:49 ` Zhang Yi
2024-08-14 5:36 ` Christoph Hellwig
2024-08-14 7:49 ` Zhang Yi
2024-08-15 5:59 ` Christoph Hellwig
2024-08-16 2:19 ` Zhang Yi
2024-08-17 4:45 ` Matthew Wilcox
2024-08-17 6:43 ` Zhang Yi
2024-08-12 12:11 ` [PATCH v2 5/6] iomap: don't mark blocks uptodate after partial zeroing Zhang Yi
2024-08-12 16:49 ` Darrick J. Wong
2024-08-13 3:01 ` Zhang Yi
2024-08-14 5:39 ` Christoph Hellwig
2024-08-17 4:48 ` Matthew Wilcox
2024-08-17 7:16 ` Zhang Yi
2024-08-12 12:11 ` [PATCH v2 6/6] iomap: reduce unnecessary state_lock when setting ifs uptodate and dirty bits Zhang Yi
2024-08-12 16:54 ` Darrick J. Wong
2024-08-12 17:00 ` Matthew Wilcox
2024-08-13 8:15 ` Zhang Yi
2024-08-14 1:49 ` Dave Chinner [this message]
2024-08-14 2:14 ` [PATCH v2 0/6] iomap: some minor non-critical fixes and improvements when block size < folio size Zhang Yi
2024-08-14 2:47 ` Dave Chinner
2024-08-14 3:57 ` Zhang Yi
2024-08-14 5:16 ` Dave Chinner
2024-08-14 6:32 ` Zhang Yi
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=ZrwNG9ftNaV4AJDd@dread.disaster.area \
--to=david@fromorbit.com \
--cc=brauner@kernel.org \
--cc=chengzhihao1@huawei.com \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=willy@infradead.org \
--cc=yi.zhang@huawei.com \
--cc=yi.zhang@huaweicloud.com \
--cc=yukuai3@huawei.com \
/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