From: Dave Chinner <david@fromorbit.com>
To: linux-xfs@vger.kernel.org
Subject: [PATCH 16/16] xfs: CIL context doesn't need to count iovecs
Date: Wed, 9 Mar 2022 16:29:37 +1100 [thread overview]
Message-ID: <20220309052937.2696447-17-david@fromorbit.com> (raw)
In-Reply-To: <20220309052937.2696447-1-david@fromorbit.com>
From: Dave Chinner <dchinner@redhat.com>
Now that we account for log opheaders in the log item formatting
code, we don't actually use the aggregated count of log iovecs in
the CIL for anything. Remove it and the tracking code that
calculates it.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Chandan Babu R <chandan.babu@oracle.com>
---
fs/xfs/xfs_log_cil.c | 22 ++++++----------------
fs/xfs/xfs_log_priv.h | 1 -
2 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/fs/xfs/xfs_log_cil.c b/fs/xfs/xfs_log_cil.c
index f887184c77a4..5179436b6603 100644
--- a/fs/xfs/xfs_log_cil.c
+++ b/fs/xfs/xfs_log_cil.c
@@ -284,22 +284,18 @@ xlog_cil_alloc_shadow_bufs(
/*
* Prepare the log item for insertion into the CIL. Calculate the difference in
- * log space and vectors it will consume, and if it is a new item pin it as
- * well.
+ * log space it will consume, and if it is a new item pin it as well.
*/
STATIC void
xfs_cil_prepare_item(
struct xlog *log,
struct xfs_log_vec *lv,
struct xfs_log_vec *old_lv,
- int *diff_len,
- int *diff_iovecs)
+ int *diff_len)
{
/* Account for the new LV being passed in */
- if (lv->lv_buf_len != XFS_LOG_VEC_ORDERED) {
+ if (lv->lv_buf_len != XFS_LOG_VEC_ORDERED)
*diff_len += lv->lv_bytes;
- *diff_iovecs += lv->lv_niovecs;
- }
/*
* If there is no old LV, this is the first time we've seen the item in
@@ -316,7 +312,6 @@ xfs_cil_prepare_item(
ASSERT(lv->lv_buf_len != XFS_LOG_VEC_ORDERED);
*diff_len -= old_lv->lv_bytes;
- *diff_iovecs -= old_lv->lv_niovecs;
lv->lv_item->li_lv_shadow = old_lv;
}
@@ -365,12 +360,10 @@ static void
xlog_cil_insert_format_items(
struct xlog *log,
struct xfs_trans *tp,
- int *diff_len,
- int *diff_iovecs)
+ int *diff_len)
{
struct xfs_log_item *lip;
-
/* Bail out if we didn't find a log item. */
if (list_empty(&tp->t_items)) {
ASSERT(0);
@@ -413,7 +406,6 @@ xlog_cil_insert_format_items(
* set the item up as though it is a new insertion so
* that the space reservation accounting is correct.
*/
- *diff_iovecs -= lv->lv_niovecs;
*diff_len -= lv->lv_bytes;
/* Ensure the lv is set up according to ->iop_size */
@@ -438,7 +430,7 @@ xlog_cil_insert_format_items(
ASSERT(IS_ALIGNED((unsigned long)lv->lv_buf, sizeof(uint64_t)));
lip->li_ops->iop_format(lip, lv);
insert:
- xfs_cil_prepare_item(log, lv, old_lv, diff_len, diff_iovecs);
+ xfs_cil_prepare_item(log, lv, old_lv, diff_len);
}
}
@@ -458,7 +450,6 @@ xlog_cil_insert_items(
struct xfs_cil_ctx *ctx = cil->xc_ctx;
struct xfs_log_item *lip;
int len = 0;
- int diff_iovecs = 0;
int iclog_space;
int iovhdr_res = 0, split_res = 0, ctx_res = 0;
@@ -468,7 +459,7 @@ xlog_cil_insert_items(
* We can do this safely because the context can't checkpoint until we
* are done so it doesn't matter exactly how we update the CIL.
*/
- xlog_cil_insert_format_items(log, tp, &len, &diff_iovecs);
+ xlog_cil_insert_format_items(log, tp, &len);
spin_lock(&cil->xc_cil_lock);
@@ -503,7 +494,6 @@ xlog_cil_insert_items(
}
tp->t_ticket->t_curr_res -= len;
ctx->space_used += len;
- ctx->nvecs += diff_iovecs;
/*
* If we've overrun the reservation, dump the tx details before we move
diff --git a/fs/xfs/xfs_log_priv.h b/fs/xfs/xfs_log_priv.h
index 3008c0c884c7..a3981567c42a 100644
--- a/fs/xfs/xfs_log_priv.h
+++ b/fs/xfs/xfs_log_priv.h
@@ -221,7 +221,6 @@ struct xfs_cil_ctx {
xfs_lsn_t commit_lsn; /* chkpt commit record lsn */
struct xlog_in_core *commit_iclog;
struct xlog_ticket *ticket; /* chkpt ticket */
- int nvecs; /* number of regions */
int space_used; /* aggregate size of regions */
struct list_head busy_extents; /* busy extents in chkpt */
struct xfs_log_vec *lv_chain; /* logvecs being pushed */
--
2.33.0
next prev parent reply other threads:[~2022-03-09 5:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 5:29 [PATCH 00/16 v8] xfs: rework xlog_write() Dave Chinner
2022-03-09 5:29 ` [PATCH 01/16] xfs: factor out the CIL transaction header building Dave Chinner
2022-03-09 5:29 ` [PATCH 02/16] xfs: only CIL pushes require a start record Dave Chinner
2022-03-09 5:29 ` [PATCH 03/16] xfs: embed the xlog_op_header in the unmount record Dave Chinner
2022-03-09 5:29 ` [PATCH 04/16] xfs: embed the xlog_op_header in the commit record Dave Chinner
2022-03-09 5:29 ` [PATCH 05/16] xfs: log tickets don't need log client id Dave Chinner
2022-03-09 5:29 ` [PATCH 06/16] xfs: move log iovec alignment to preparation function Dave Chinner
2022-03-09 5:29 ` [PATCH 07/16] xfs: reserve space and initialise xlog_op_header in item formatting Dave Chinner
2022-03-09 5:29 ` [PATCH 08/16] xfs: log ticket region debug is largely useless Dave Chinner
2022-03-09 5:29 ` [PATCH 09/16] xfs: pass lv chain length into xlog_write() Dave Chinner
2022-03-09 5:29 ` [PATCH 10/16] xfs: change the type of ic_datap Dave Chinner
2022-03-09 5:29 ` [PATCH 11/16] xfs: introduce xlog_write_full() Dave Chinner
2022-03-09 5:29 ` [PATCH 12/16] xfs: introduce xlog_write_partial() Dave Chinner
2022-03-09 5:29 ` [PATCH 13/16] xfs: remove xlog_verify_dest_ptr Dave Chinner
2022-03-09 5:29 ` [PATCH 14/16] xfs: xlog_write() no longer needs contwr state Dave Chinner
2022-03-09 5:29 ` [PATCH 15/16] xfs: xlog_write() doesn't need optype anymore Dave Chinner
2022-03-09 5:29 ` Dave Chinner [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-11-18 23:13 [PATCH 00/16 v7] xfs: rework xlog_write() Dave Chinner
2021-11-18 23:13 ` [PATCH 16/16] xfs: CIL context doesn't need to count iovecs Dave Chinner
2021-11-24 8:55 ` Chandan Babu R
2021-11-09 1:50 [PATCH 00/16 v6] xfs: rework xlog_write() Dave Chinner
2021-11-09 1:50 ` [PATCH 16/16] xfs: CIL context doesn't need to count iovecs Dave Chinner
2021-11-11 8:29 ` 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=20220309052937.2696447-17-david@fromorbit.com \
--to=david@fromorbit.com \
--cc=linux-xfs@vger.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).