public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Chandan Babu R <chandan.babu@oracle.com>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 16/16] xfs: CIL context doesn't need to count iovecs
Date: Wed, 24 Nov 2021 14:25:17 +0530	[thread overview]
Message-ID: <87v90irkzu.fsf@debian-BULLSEYE-live-builder-AMD64> (raw)
In-Reply-To: <20211118231352.2051947-17-david@fromorbit.com>

On 19 Nov 2021 at 04:43, Dave Chinner wrote:
> 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.
>

Looks good.

Reviewed-by: Chandan Babu R <chandan.babu@oracle.com>

> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> Reviewed-by: Darrick J. Wong <djwong@kernel.org>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> ---
>  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 ad98e4df0e2c..f7ca7a4e6fa5 100644
> --- a/fs/xfs/xfs_log_cil.c
> +++ b/fs/xfs/xfs_log_cil.c
> @@ -260,22 +260,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
> @@ -292,7 +288,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;
>  	}
>  
> @@ -341,12 +336,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);
> @@ -389,7 +382,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 */
> @@ -414,7 +406,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);
>  	}
>  }
>  
> @@ -434,7 +426,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;
>  
> @@ -444,7 +435,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);
>  
> @@ -479,7 +470,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 */


-- 
chandan

  reply	other threads:[~2021-11-24  8:55 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-18 23:13 [PATCH 00/16 v7] xfs: rework xlog_write() Dave Chinner
2021-11-18 23:13 ` [PATCH 01/16] xfs: factor out the CIL transaction header building Dave Chinner
2021-11-22 10:48   ` Chandan Babu R
2021-11-18 23:13 ` [PATCH 02/16] xfs: only CIL pushes require a start record Dave Chinner
2021-11-22 11:29   ` Chandan Babu R
2021-11-18 23:13 ` [PATCH 03/16] xfs: embed the xlog_op_header in the unmount record Dave Chinner
2021-11-22 11:30   ` Chandan Babu R
2021-11-18 23:13 ` [PATCH 04/16] xfs: embed the xlog_op_header in the commit record Dave Chinner
2021-11-22 11:31   ` Chandan Babu R
2021-11-18 23:13 ` [PATCH 05/16] xfs: log tickets don't need log client id Dave Chinner
2021-11-22 11:37   ` Chandan Babu R
2021-11-18 23:13 ` [PATCH 06/16] xfs: move log iovec alignment to preparation function Dave Chinner
2021-11-22 11:37   ` Chandan Babu R
2021-11-18 23:13 ` [PATCH 07/16] xfs: reserve space and initialise xlog_op_header in item formatting Dave Chinner
2021-11-22 11:39   ` Chandan Babu R
2021-11-18 23:13 ` [PATCH 08/16] xfs: log ticket region debug is largely useless Dave Chinner
2021-11-22 11:39   ` Chandan Babu R
2021-11-18 23:13 ` [PATCH 09/16] xfs: pass lv chain length into xlog_write() Dave Chinner
2021-11-22 11:39   ` Chandan Babu R
2021-11-18 23:13 ` [PATCH 10/16] xfs: change the type of ic_datap Dave Chinner
2021-11-18 23:13 ` [PATCH 11/16] xfs: introduce xlog_write_full() Dave Chinner
2021-11-22 11:40   ` Chandan Babu R
2021-11-18 23:13 ` [PATCH 12/16] xfs: introduce xlog_write_partial() Dave Chinner
2021-11-23 16:13   ` Chandan Babu R
2021-11-23 21:47   ` Darrick J. Wong
2021-11-18 23:13 ` [PATCH 13/16] xfs: remove xlog_verify_dest_ptr Dave Chinner
2021-11-18 23:13 ` [PATCH 14/16] xfs: xlog_write() no longer needs contwr state Dave Chinner
2021-11-24  8:54   ` Chandan Babu R
2021-11-18 23:13 ` [PATCH 15/16] xfs: xlog_write() doesn't need optype anymore Dave Chinner
2021-11-24  8:55   ` Chandan Babu R
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 [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-03-09  5:29 [PATCH 00/16 v8] xfs: rework xlog_write() Dave Chinner
2022-03-09  5:29 ` [PATCH 16/16] xfs: CIL context doesn't need to count iovecs Dave Chinner
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=87v90irkzu.fsf@debian-BULLSEYE-live-builder-AMD64 \
    --to=chandan.babu@oracle.com \
    --cc=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