From: Long Li <leo.lilong@huawei.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: <chandanbabu@kernel.org>, <linux-xfs@vger.kernel.org>,
<david@fromorbit.com>, <yi.zhang@huawei.com>,
<houtao1@huawei.com>, <yangerkun@huawei.com>
Subject: Re: [PATCH] xfs: get rid of xfs_ag_resv_rmapbt_alloc
Date: Wed, 3 Jul 2024 14:33:55 +0800 [thread overview]
Message-ID: <20240703063355.GA518841@ceph-admin> (raw)
In-Reply-To: <20240703051446.GF612460@frogsfrogsfrogs>
On Tue, Jul 02, 2024 at 10:14:46PM -0700, Darrick J. Wong wrote:
> On Tue, Jul 02, 2024 at 09:48:51PM +0800, Long Li wrote:
> > The pag in xfs_ag_resv_rmapbt_alloc() is already held when the struct
> > xfs_btree_cur is initialized in xfs_rmapbt_init_cursor(), so there is no
> > need to get pag again.
> >
> > On the other hand, in xfs_rmapbt_free_block(), the similar function
> > xfs_ag_resv_rmapbt_free() was removed in commit 92a005448f6f ("xfs: get
> > rid of unnecessary xfs_perag_{get,put} pairs"), xfs_ag_resv_rmapbt_alloc()
> > was left because scrub used it, but now scrub has removed it. Therefore,
> > we could get rid of xfs_ag_resv_rmapbt_alloc() just like the rmap free
> > block, make the code cleaner.
> >
> > Signed-off-by: Long Li <leo.lilong@huawei.com>
> > ---
> > fs/xfs/libxfs/xfs_ag_resv.h | 19 -------------------
> > fs/xfs/libxfs/xfs_rmap_btree.c | 8 +++++++-
> > 2 files changed, 7 insertions(+), 20 deletions(-)
> >
> > diff --git a/fs/xfs/libxfs/xfs_ag_resv.h b/fs/xfs/libxfs/xfs_ag_resv.h
> > index ff20ed93de77..f247eeff7358 100644
> > --- a/fs/xfs/libxfs/xfs_ag_resv.h
> > +++ b/fs/xfs/libxfs/xfs_ag_resv.h
> > @@ -33,23 +33,4 @@ xfs_perag_resv(
> > }
> > }
> >
> > -/*
> > - * RMAPBT reservation accounting wrappers. Since rmapbt blocks are sourced from
> > - * the AGFL, they are allocated one at a time and the reservation updates don't
> > - * require a transaction.
> > - */
> > -static inline void
> > -xfs_ag_resv_rmapbt_alloc(
> > - struct xfs_mount *mp,
> > - xfs_agnumber_t agno)
> > -{
> > - struct xfs_alloc_arg args = { NULL };
> > - struct xfs_perag *pag;
> > -
> > - args.len = 1;
> > - pag = xfs_perag_get(mp, agno);
> > - xfs_ag_resv_alloc_extent(pag, XFS_AG_RESV_RMAPBT, &args);
> > - xfs_perag_put(pag);
> > -}
> > -
> > #endif /* __XFS_AG_RESV_H__ */
> > diff --git a/fs/xfs/libxfs/xfs_rmap_btree.c b/fs/xfs/libxfs/xfs_rmap_btree.c
> > index 9e759efa81cc..aa1d29814b74 100644
> > --- a/fs/xfs/libxfs/xfs_rmap_btree.c
> > +++ b/fs/xfs/libxfs/xfs_rmap_btree.c
> > @@ -88,6 +88,7 @@ xfs_rmapbt_alloc_block(
> > struct xfs_buf *agbp = cur->bc_ag.agbp;
> > struct xfs_agf *agf = agbp->b_addr;
> > struct xfs_perag *pag = cur->bc_ag.pag;
> > + struct xfs_alloc_arg args = { NULL };
>
> You could make this even more compact with
>
> struct xfs_alloc_arg args = { .len = 1 };
It's ok for me, I will send a new version. thanks!
>
> Otherwise this looks ok to me as a cleanup.
>
> --D
>
> > int error;
> > xfs_agblock_t bno;
> >
> > @@ -107,7 +108,12 @@ xfs_rmapbt_alloc_block(
> > be32_add_cpu(&agf->agf_rmap_blocks, 1);
> > xfs_alloc_log_agf(cur->bc_tp, agbp, XFS_AGF_RMAP_BLOCKS);
> >
> > - xfs_ag_resv_rmapbt_alloc(cur->bc_mp, pag->pag_agno);
> > + /*
> > + * Since rmapbt blocks are sourced from the AGFL, they are allocated one
> > + * at a time and the reservation updates don't require a transaction.
> > + */
> > + args.len = 1;
> > + xfs_ag_resv_alloc_extent(pag, XFS_AG_RESV_RMAPBT, &args);
> >
> > *stat = 1;
> > return 0;
> > --
> > 2.39.2
> >
> >
prev parent reply other threads:[~2024-07-03 6:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-02 13:48 [PATCH] xfs: get rid of xfs_ag_resv_rmapbt_alloc Long Li
2024-07-03 5:14 ` Darrick J. Wong
2024-07-03 6:33 ` Long Li [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=20240703063355.GA518841@ceph-admin \
--to=leo.lilong@huawei.com \
--cc=chandanbabu@kernel.org \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=houtao1@huawei.com \
--cc=linux-xfs@vger.kernel.org \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.