From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: wangyufei <wangyufei@vivo.com>,
viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
cem@kernel.org, kundan.kumar@samsung.com, anuj20.g@samsung.com,
bernd@bsbernd.com, david@fromorbit.com,
linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, opensource.kernel@vivo.com
Subject: Re: [RFC 2/2] xfs: implement get_inode_wb_ctx_idx() for per-AG parallel writeback
Date: Tue, 23 Sep 2025 11:46:55 -0700 [thread overview]
Message-ID: <20250923184655.GF1587915@frogsfrogsfrogs> (raw)
In-Reply-To: <20250922165642.GA11520@lst.de>
On Mon, Sep 22, 2025 at 06:56:42PM +0200, Christoph Hellwig wrote:
> On Sun, Sep 14, 2025 at 08:11:09PM +0800, wangyufei wrote:
> > The number of writeback contexts is set to the number of CPUs by
> > default. This allows XFS to decide how to assign inodes to writeback
> > contexts based on its allocation groups.
> >
> > Implement get_inode_wb_ctx_idx() in xfs_super_operations as follows:
> > - Limit the number of active writeback contexts to the number of AGs.
> > - Assign inodes from the same AG to a unique writeback context.
>
> I'm not sure this actually works. Data is spread over AGs, just with
> a default to the parent inode AG if there is space, and even that isn't
> true for the inode32 option or when using the RT subvolume.
I don't know of a better way to shard cheaply -- if you could group
inodes dynamically by a rough estimate of the AGs that map to the dirty
data (especially delalloc/unwritten/cow mappings) then that would be an
improvement, but that's still far from what I would consider the ideal.
Ideally (maybe?) one could shard dirty ranges first by the amount of
effort (pure overwrite; secondly backed-by-unwritten; thirdly
delalloc/cow). The first two groups could then be sharded by AG and
issued in parallel. The third group involve so much metadata changes
that you could probably just shard evenly across CPUs. Writebacks get
initiated in that order, and then we see where the bottlenecks lie in
ioend completion.
(But that's just my hazy untested brai^Widea :P)
--D
> > +
> > + if (mp->m_sb.sb_agcount <= nr_wb_ctx)
> > + return XFS_INO_TO_AGNO(mp, xfs_inode->i_ino);
> > + return xfs_inode->i_ino % nr_wb_ctx;
> > +}
> > +
> > static const struct super_operations xfs_super_operations = {
> > .alloc_inode = xfs_fs_alloc_inode,
> > .destroy_inode = xfs_fs_destroy_inode,
> > @@ -1295,6 +1308,7 @@ static const struct super_operations xfs_super_operations = {
> > .free_cached_objects = xfs_fs_free_cached_objects,
> > .shutdown = xfs_fs_shutdown,
> > .show_stats = xfs_fs_show_stats,
> > + .get_inode_wb_ctx_idx = xfs_fs_get_inode_wb_ctx_idx,
> > };
> >
> > static int
> > --
> > 2.34.1
> ---end quoted text---
>
prev parent reply other threads:[~2025-09-23 18:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-14 12:11 [RFC 0/2] writeback: add support for filesystems to optimize parallel writeback wangyufei
2025-09-14 12:11 ` [RFC 1/2] writeback: add support for filesystems to affine inodes to specific writeback ctx wangyufei
2025-09-14 12:11 ` [RFC 2/2] xfs: implement get_inode_wb_ctx_idx() for per-AG parallel writeback wangyufei
2025-09-22 16:56 ` Christoph Hellwig
2025-09-23 18:46 ` Darrick J. Wong [this message]
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=20250923184655.GF1587915@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=anuj20.g@samsung.com \
--cc=bernd@bsbernd.com \
--cc=brauner@kernel.org \
--cc=cem@kernel.org \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=kundan.kumar@samsung.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=opensource.kernel@vivo.com \
--cc=viro@zeniv.linux.org.uk \
--cc=wangyufei@vivo.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