From: Dave Chinner <david@fromorbit.com>
To: linux-xfs@vger.kernel.org
Subject: [PATCH 4/9] xfs: ensure log tail is always up to date
Date: Wed, 21 Dec 2022 10:23:03 +1100 [thread overview]
Message-ID: <20221220232308.3482960-5-david@fromorbit.com> (raw)
In-Reply-To: <20221220232308.3482960-1-david@fromorbit.com>
From: Dave Chinner <dchinner@redhat.com>
Whenever we write an iclog, we call xlog_assign_tail_lsn() to update
the current tail before we write it into the iclog header. This
means we have to take the AIL lock on every iclog write just to
check if the tail of the log has moved.
This doesn't avoid races with log tail updates - the log tail could
move immediately after we assign the tail to the iclog header and
hence by the time the iclog reaches stable storage the tail LSN has
moved forward in memory. Hence the log tail LSN in the iclog header
is really just a point in time snapshot of the current state of the
AIL.
With this in mind, if we simply update the in memory log->l_tail_lsn
every time it changes in the AIL, there is no need to update the in
memory value when we are writing it into an iclog - it will already
be up-to-date in memory and checking the AIL again will not change
this. Hence xlog_state_release_iclog() does not need to check the
AIL to update the tail lsn and can just sample it directly without
needing to take the AIL lock.
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.c | 5 ++---
fs/xfs/xfs_trans_ail.c | 17 +++++++++++++++--
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c
index 7de23639a2a2..473f585aa930 100644
--- a/fs/xfs/xfs_log.c
+++ b/fs/xfs/xfs_log.c
@@ -530,7 +530,6 @@ xlog_state_release_iclog(
struct xlog_in_core *iclog,
struct xlog_ticket *ticket)
{
- xfs_lsn_t tail_lsn;
bool last_ref;
lockdep_assert_held(&log->l_icloglock);
@@ -545,8 +544,8 @@ xlog_state_release_iclog(
if ((iclog->ic_state == XLOG_STATE_WANT_SYNC ||
(iclog->ic_flags & XLOG_ICL_NEED_FUA)) &&
!iclog->ic_header.h_tail_lsn) {
- tail_lsn = xlog_assign_tail_lsn(log->l_mp);
- iclog->ic_header.h_tail_lsn = cpu_to_be64(tail_lsn);
+ iclog->ic_header.h_tail_lsn =
+ cpu_to_be64(atomic64_read(&log->l_tail_lsn));
}
last_ref = atomic_dec_and_test(&iclog->ic_refcnt);
diff --git a/fs/xfs/xfs_trans_ail.c b/fs/xfs/xfs_trans_ail.c
index 7354b5379014..0274e478d8a0 100644
--- a/fs/xfs/xfs_trans_ail.c
+++ b/fs/xfs/xfs_trans_ail.c
@@ -715,6 +715,13 @@ xfs_ail_push_all_sync(
finish_wait(&ailp->ail_empty, &wait);
}
+/*
+ * Callers should pass the the original tail lsn so that we can detect if the
+ * tail has moved as a result of the operation that was performed. If the caller
+ * needs to force a tail LSN update, it should pass NULLCOMMITLSN to bypass the
+ * "did the tail LSN change?" checks. If the caller wants to avoid a tail update
+ * (e.g. it knows the tail did not change) it should pass an @old_lsn of 0.
+ */
void
xfs_ail_update_finish(
struct xfs_ail *ailp,
@@ -799,10 +806,16 @@ xfs_trans_ail_update_bulk(
/*
* If this is the first insert, wake up the push daemon so it can
- * actively scan for items to push.
+ * actively scan for items to push. We also need to do a log tail
+ * LSN update to ensure that it is correctly tracked by the log, so
+ * set the tail_lsn to NULLCOMMITLSN so that xfs_ail_update_finish()
+ * will see that the tail lsn has changed and will update the tail
+ * appropriately.
*/
- if (!mlip)
+ if (!mlip) {
wake_up_process(ailp->ail_task);
+ tail_lsn = NULLCOMMITLSN;
+ }
xfs_ail_update_finish(ailp, tail_lsn);
}
--
2.38.1
next prev parent reply other threads:[~2022-12-20 23:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-20 23:22 [PATCH 0/9 v3] xfs: byte-based grant head reservation tracking Dave Chinner
2022-12-20 23:23 ` [PATCH 1/9] xfs: move and xfs_trans_committed_bulk Dave Chinner
2022-12-20 23:23 ` [PATCH 2/9] xfs: AIL doesn't need manual pushing Dave Chinner
2022-12-20 23:23 ` [PATCH 3/9] xfs: background AIL push targets physical space, not grant space Dave Chinner
2022-12-20 23:23 ` Dave Chinner [this message]
2022-12-20 23:23 ` [PATCH 5/9] xfs: l_last_sync_lsn is really AIL state Dave Chinner
2022-12-20 23:23 ` [PATCH 6/9] xfs: collapse xlog_state_set_callback in caller Dave Chinner
2022-12-20 23:23 ` [PATCH 7/9] xfs: track log space pinned by the AIL Dave Chinner
2022-12-20 23:23 ` [PATCH 8/9] xfs: pass the full grant head to accounting functions Dave Chinner
2022-12-20 23:23 ` [PATCH 9/9] xfs: grant heads track byte counts, not LSNs Dave Chinner
-- strict thread matches above, loose matches on Subject: below --
2023-09-21 1:48 [PATCH 0/9] xfs: byte-based grant head reservation tracking Dave Chinner
2023-09-21 1:48 ` [PATCH 4/9] xfs: ensure log tail is always up to date Dave Chinner
2022-08-09 23:03 [PATCH 0/9 v2] xfs: byte-base grant head reservation tracking Dave Chinner
2022-08-09 23:03 ` [PATCH 4/9] xfs: ensure log tail is always up to date Dave Chinner
2022-08-23 0:33 ` Darrick J. Wong
2022-08-23 2:18 ` Dave Chinner
2022-08-26 21:39 ` Darrick J. Wong
2022-08-26 23:49 ` Darrick J. Wong
2022-09-07 14:06 ` 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=20221220232308.3482960-5-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).