From: Brian Foster <bfoster@redhat.com>
To: Shaohua Li <shli@kernel.org>
Cc: linux-xfs@vger.kernel.org, Kernel-team@fb.com,
Shaohua Li <shli@fb.com>, Tejun Heo <tj@kernel.org>,
"Darrick J . Wong" <darrick.wong@oracle.com>,
Dave Chinner <david@fromorbit.com>,
Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH V2] xfs: implement cgroup writeback support
Date: Fri, 23 Mar 2018 10:37:40 -0400 [thread overview]
Message-ID: <20180323143740.GD22357@bfoster.bfoster> (raw)
In-Reply-To: <f13839700d372a4663a08a11883e9c89b13056ca.1521752282.git.shli@fb.com>
On Thu, Mar 22, 2018 at 02:11:45PM -0700, Shaohua Li wrote:
> From: Shaohua Li <shli@fb.com>
>
> Basically this is a copy of commit 001e4a8775f6(ext4: implement cgroup
> writeback support). Tested with a fio test, verified writeback is
> throttled against cgroup io.max write bandwidth, also verified moving
> the fio test to another cgroup and the writeback is throttled against
> new cgroup setting.
>
> This only controls the file data write for cgroup. For metadata, since
> xfs dispatches the metadata write in specific threads, it's possible low
> prio app's metadata could harm high prio app's metadata. A while back,
> Tejun has a patch to force metadata belonging to root cgroup for btrfs.
> I had a similiar patch for xfs too. But Since Tejun's patch isn't in
> upstream, I'll delay post the xfs patch.
>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Darrick J. Wong <darrick.wong@oracle.com>
> Cc: Dave Chinner <david@fromorbit.com>
> Cc: Christoph Hellwig <hch@infradead.org>
> Signed-off-by: Shaohua Li <shli@fb.com>
> ---
> fs/xfs/xfs_aops.c | 13 +++++++++++--
> fs/xfs/xfs_super.c | 1 +
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
> index 19eadc8..5f70584 100644
> --- a/fs/xfs/xfs_aops.c
> +++ b/fs/xfs/xfs_aops.c
> @@ -589,7 +589,8 @@ xfs_alloc_ioend(
> struct inode *inode,
> unsigned int type,
> xfs_off_t offset,
> - struct buffer_head *bh)
> + struct buffer_head *bh,
> + struct writeback_control *wbc)
> {
> struct xfs_ioend *ioend;
> struct bio *bio;
> @@ -606,6 +607,8 @@ xfs_alloc_ioend(
> INIT_WORK(&ioend->io_work, xfs_end_io);
> ioend->io_append_trans = NULL;
> ioend->io_bio = bio;
> + /* attach new bio to its cgroup */
> + wbc_init_bio(wbc, bio);
Just a nit, but can we move the wbc_init_bio() calls to earlier in the
function where we setup/init the bio? (Same comment for
xfs_chain_bio()). Otherwise this looks fine to me and passes the posted
xfstests test.
Brian
> return ioend;
> }
>
> @@ -633,6 +636,8 @@ xfs_chain_bio(
> ioend->io_bio->bi_write_hint = ioend->io_inode->i_write_hint;
> submit_bio(ioend->io_bio);
> ioend->io_bio = new;
> + /* attach new bio to its cgroup */
> + wbc_init_bio(wbc, new);
> }
>
> /*
> @@ -656,7 +661,8 @@ xfs_add_to_ioend(
> offset != wpc->ioend->io_offset + wpc->ioend->io_size) {
> if (wpc->ioend)
> list_add(&wpc->ioend->io_list, iolist);
> - wpc->ioend = xfs_alloc_ioend(inode, wpc->io_type, offset, bh);
> + wpc->ioend = xfs_alloc_ioend(inode, wpc->io_type, offset,
> + bh, wbc);
> }
>
> /*
> @@ -666,6 +672,9 @@ xfs_add_to_ioend(
> while (xfs_bio_add_buffer(wpc->ioend->io_bio, bh) != bh->b_size)
> xfs_chain_bio(wpc->ioend, wbc, bh);
>
> + /* Charge write size to its cgroup for cgroup switching track */
> + wbc_account_io(wbc, bh->b_page, bh->b_size);
> +
> wpc->ioend->io_size += bh->b_size;
> wpc->last_block = bh->b_blocknr;
> xfs_start_buffer_writeback(bh);
> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
> index 951271f..95c2d3d 100644
> --- a/fs/xfs/xfs_super.c
> +++ b/fs/xfs/xfs_super.c
> @@ -1666,6 +1666,7 @@ xfs_fs_fill_super(
> sb->s_max_links = XFS_MAXLINK;
> sb->s_time_gran = 1;
> set_posix_acl_flag(sb);
> + sb->s_iflags |= SB_I_CGROUPWB;
>
> /* version 5 superblocks support inode version counters. */
> if (XFS_SB_VERSION_NUM(&mp->m_sb) == XFS_SB_VERSION_5)
> --
> 2.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-03-23 14:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-22 21:11 [PATCH V2] xfs: implement cgroup writeback support Shaohua Li
2018-03-23 14:00 ` Chris Mason
2018-03-23 14:24 ` 张本龙
2018-03-25 21:59 ` Dave Chinner
2018-03-26 16:28 ` Brian Foster
2018-03-27 0:55 ` Shaohua Li
2018-03-27 11:36 ` Brian Foster
2018-03-27 21:56 ` Dave Chinner
2018-03-28 11:32 ` Brian Foster
2018-03-28 22:35 ` Dave Chinner
2018-03-28 4:37 ` 张本龙
2018-03-28 11:24 ` Brian Foster
[not found] ` <CAJDdQW3gOa8ry_XVkcCMf2QT7wC7MvU4b94hMhwJsg9MjYoKgQ@mail.gmail.com>
2018-03-27 11:50 ` Brian Foster
2018-03-28 9:55 ` 张本龙
2018-03-23 14:37 ` Brian Foster [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-10-15 5:07 Shaohua Li
2017-10-15 22:22 ` Dave Chinner
2017-10-16 3:35 ` Shaohua Li
2017-10-16 6:22 ` Dave Chinner
2017-10-18 5:18 ` Shaohua Li
2017-10-19 7:35 ` Christoph Hellwig
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=20180323143740.GD22357@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=Kernel-team@fb.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=linux-xfs@vger.kernel.org \
--cc=shli@fb.com \
--cc=shli@kernel.org \
--cc=tj@kernel.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).