linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: linux-xfs@vger.kernel.org
Subject: [PATCH 06/16] xfs: move log iovec alignment to preparation function
Date: Wed,  9 Mar 2022 16:29:27 +1100	[thread overview]
Message-ID: <20220309052937.2696447-7-david@fromorbit.com> (raw)
In-Reply-To: <20220309052937.2696447-1-david@fromorbit.com>

From: Dave Chinner <dchinner@redhat.com>

To include log op headers directly into the log iovec regions that
the ophdrs wrap, we need to move the buffer alignment code from
xlog_finish_iovec() to xlog_prepare_iovec(). This is because the
xlog_op_header is only 12 bytes long, and we need the buffer that
the caller formats their data into to be 8 byte aligned.

Hence once we start prepending the ophdr in xlog_prepare_iovec(), we
are going to need to manage the padding directly to ensure that the
buffer pointer returned is correctly aligned.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Chandan Babu R <chandan.babu@oracle.com>
---
 fs/xfs/xfs_log.h | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/fs/xfs/xfs_log.h b/fs/xfs/xfs_log.h
index 09b8fe9994f2..d1fc43476166 100644
--- a/fs/xfs/xfs_log.h
+++ b/fs/xfs/xfs_log.h
@@ -21,6 +21,16 @@ struct xfs_log_vec {
 
 #define XFS_LOG_VEC_ORDERED	(-1)
 
+/*
+ * We need to make sure the buffer pointer returned is naturally aligned for the
+ * biggest basic data type we put into it. We have already accounted for this
+ * padding when sizing the buffer.
+ *
+ * However, this padding does not get written into the log, and hence we have to
+ * track the space used by the log vectors separately to prevent log space hangs
+ * due to inaccurate accounting (i.e. a leak) of the used log space through the
+ * CIL context ticket.
+ */
 static inline void *
 xlog_prepare_iovec(struct xfs_log_vec *lv, struct xfs_log_iovec **vecp,
 		uint type)
@@ -34,6 +44,9 @@ xlog_prepare_iovec(struct xfs_log_vec *lv, struct xfs_log_iovec **vecp,
 		vec = &lv->lv_iovecp[0];
 	}
 
+	if (!IS_ALIGNED(lv->lv_buf_len, sizeof(uint64_t)))
+		lv->lv_buf_len = round_up(lv->lv_buf_len, sizeof(uint64_t));
+
 	vec->i_type = type;
 	vec->i_addr = lv->lv_buf + lv->lv_buf_len;
 
@@ -43,20 +56,10 @@ xlog_prepare_iovec(struct xfs_log_vec *lv, struct xfs_log_iovec **vecp,
 	return vec->i_addr;
 }
 
-/*
- * We need to make sure the next buffer is naturally aligned for the biggest
- * basic data type we put into it.  We already accounted for this padding when
- * sizing the buffer.
- *
- * However, this padding does not get written into the log, and hence we have to
- * track the space used by the log vectors separately to prevent log space hangs
- * due to inaccurate accounting (i.e. a leak) of the used log space through the
- * CIL context ticket.
- */
 static inline void
 xlog_finish_iovec(struct xfs_log_vec *lv, struct xfs_log_iovec *vec, int len)
 {
-	lv->lv_buf_len += round_up(len, sizeof(uint64_t));
+	lv->lv_buf_len += len;
 	lv->lv_bytes += len;
 	vec->i_len = len;
 }
-- 
2.33.0


  parent reply	other threads:[~2022-03-09  5:29 UTC|newest]

Thread overview: 20+ 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 ` Dave Chinner [this message]
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 ` [PATCH 16/16] xfs: CIL context doesn't need to count iovecs Dave Chinner
  -- 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 06/16] xfs: move log iovec alignment to preparation function Dave Chinner
2021-11-22 11:37   ` Chandan Babu R
2021-11-09  1:50 [PATCH 00/16 v6] xfs: rework xlog_write() Dave Chinner
2021-11-09  1:50 ` [PATCH 06/16] xfs: move log iovec alignment to preparation function Dave Chinner

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-7-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).