From: Dave Chinner <david@fromorbit.com>
To: linux-xfs@vger.kernel.org
Subject: [PATCH 3/9] xfs: background AIL push targets physical space, not grant space
Date: Thu, 21 Sep 2023 11:48:38 +1000 [thread overview]
Message-ID: <20230921014844.582667-4-david@fromorbit.com> (raw)
In-Reply-To: <20230921014844.582667-1-david@fromorbit.com>
From: Dave Chinner <dchinner@redhat.com>
Currently the AIL attempts to keep 25% of the "log space" free,
where the current used space is tracked by the reserve grant head.
That is, it tracks both physical space used plus the amount reserved
by transactions in progress.
When we start tail pushing, we are trying to make space for new
reservations by writing back older metadata and the log is generally
physically full of dirty metadata, and reservations for modifications
in flight take up whatever space the AIL can physically free up.
Hence we don't really need to take into account the reservation
space that has been used - we just need to keep the log tail moving
as fast as we can to free up space for more reservations to be made.
We know exactly how much physical space the journal is consuming in
the AIL (i.e. max LSN - min LSN) so we can base push thresholds
directly on this state rather than have to look at grant head
reservations to determine how much to physically push out of the
log.
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_priv.h | 18 ++++++++++++
fs/xfs/xfs_trans_ail.c | 63 +++++++++++++++++++-----------------------
2 files changed, 47 insertions(+), 34 deletions(-)
diff --git a/fs/xfs/xfs_log_priv.h b/fs/xfs/xfs_log_priv.h
index d4124ef9d97f..01c333f712ae 100644
--- a/fs/xfs/xfs_log_priv.h
+++ b/fs/xfs/xfs_log_priv.h
@@ -625,6 +625,24 @@ xlog_wait(
int xlog_wait_on_iclog(struct xlog_in_core *iclog);
+/* Calculate the distance between two LSNs in bytes */
+static inline uint64_t
+xlog_lsn_sub(
+ struct xlog *log,
+ xfs_lsn_t high,
+ xfs_lsn_t low)
+{
+ uint32_t hi_cycle = CYCLE_LSN(high);
+ uint32_t hi_block = BLOCK_LSN(high);
+ uint32_t lo_cycle = CYCLE_LSN(low);
+ uint32_t lo_block = BLOCK_LSN(low);
+
+ if (hi_cycle == lo_cycle)
+ return BBTOB(hi_block - lo_block);
+ ASSERT((hi_cycle == lo_cycle + 1) || xlog_is_shutdown(log));
+ return (uint64_t)log->l_logsize - BBTOB(lo_block - hi_block);
+}
+
/*
* The LSN is valid so long as it is behind the current LSN. If it isn't, this
* means that the next log record that includes this metadata could have a
diff --git a/fs/xfs/xfs_trans_ail.c b/fs/xfs/xfs_trans_ail.c
index 31a4e5e5d899..3103e16d6965 100644
--- a/fs/xfs/xfs_trans_ail.c
+++ b/fs/xfs/xfs_trans_ail.c
@@ -398,51 +398,46 @@ xfsaild_push_item(
/*
* Compute the LSN that we'd need to push the log tail towards in order to have
* at least 25% of the log space free. If the log free space already meets this
- * threshold, this function returns NULLCOMMITLSN.
+ * threshold, this function returns the lowest LSN in the AIL to slowly keep
+ * writeback ticking over and the tail of the log moving forward.
*/
xfs_lsn_t
__xfs_ail_push_target(
struct xfs_ail *ailp)
{
- struct xlog *log = ailp->ail_log;
- xfs_lsn_t threshold_lsn = 0;
- xfs_lsn_t last_sync_lsn;
- int free_blocks;
- int free_bytes;
- int threshold_block;
- int threshold_cycle;
- int free_threshold;
+ struct xlog *log = ailp->ail_log;
+ struct xfs_log_item *lip;
+ xfs_lsn_t target_lsn = 0;
+ xfs_lsn_t max_lsn;
+ xfs_lsn_t min_lsn;
+ int32_t free_bytes;
+ uint32_t target_block;
+ uint32_t target_cycle;
- free_bytes = xlog_space_left(log, &log->l_reserve_head.grant);
- free_blocks = BTOBBT(free_bytes);
+ lockdep_assert_held(&ailp->ail_lock);
- /*
- * The threshold for the minimum number of free blocks is one quarter of
- * the entire log space.
- */
- free_threshold = log->l_logBBsize >> 2;
- if (free_blocks >= free_threshold)
+ lip = xfs_ail_max(ailp);
+ if (!lip)
return NULLCOMMITLSN;
+ max_lsn = lip->li_lsn;
+ min_lsn = __xfs_ail_min_lsn(ailp);
- xlog_crack_atomic_lsn(&log->l_tail_lsn, &threshold_cycle,
- &threshold_block);
- threshold_block += free_threshold;
- if (threshold_block >= log->l_logBBsize) {
- threshold_block -= log->l_logBBsize;
- threshold_cycle += 1;
+ free_bytes = log->l_logsize - xlog_lsn_sub(log, max_lsn, min_lsn);
+ if (free_bytes >= log->l_logsize >> 2)
+ return NULLCOMMITLSN;
+
+ target_cycle = CYCLE_LSN(min_lsn);
+ target_block = BLOCK_LSN(min_lsn) + (log->l_logBBsize >> 2);
+ if (target_block >= log->l_logBBsize) {
+ target_block -= log->l_logBBsize;
+ target_cycle += 1;
}
- threshold_lsn = xlog_assign_lsn(threshold_cycle,
- threshold_block);
- /*
- * Don't pass in an lsn greater than the lsn of the last
- * log record known to be on disk. Use a snapshot of the last sync lsn
- * so that it doesn't change between the compare and the set.
- */
- last_sync_lsn = atomic64_read(&log->l_last_sync_lsn);
- if (XFS_LSN_CMP(threshold_lsn, last_sync_lsn) > 0)
- threshold_lsn = last_sync_lsn;
+ target_lsn = xlog_assign_lsn(target_cycle, target_block);
- return threshold_lsn;
+ /* Cap the target to the highest LSN known to be in the AIL. */
+ if (XFS_LSN_CMP(target_lsn, max_lsn) > 0)
+ return max_lsn;
+ return target_lsn;
}
static long
--
2.40.1
next prev parent reply other threads:[~2023-09-21 1:48 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-21 1:48 [PATCH 0/9] xfs: byte-based grant head reservation tracking Dave Chinner
2023-09-21 1:48 ` [PATCH 1/9] xfs: move and xfs_trans_committed_bulk Dave Chinner
2023-10-12 8:54 ` Christoph Hellwig
2023-09-21 1:48 ` [PATCH 2/9] xfs: AIL doesn't need manual pushing Dave Chinner
2023-09-21 22:20 ` Darrick J. Wong
2023-09-21 1:48 ` Dave Chinner [this message]
2023-09-21 1:48 ` [PATCH 4/9] xfs: ensure log tail is always up to date Dave Chinner
2023-09-21 1:48 ` [PATCH 5/9] xfs: l_last_sync_lsn is really AIL state Dave Chinner
2023-09-21 22:22 ` Darrick J. Wong
2023-09-21 1:48 ` [PATCH 6/9] xfs: collapse xlog_state_set_callback in caller Dave Chinner
2023-09-21 1:48 ` [PATCH 7/9] xfs: track log space pinned by the AIL Dave Chinner
2023-10-12 8:47 ` Christoph Hellwig
2023-09-21 1:48 ` [PATCH 8/9] xfs: pass the full grant head to accounting functions Dave Chinner
2023-10-12 8:50 ` Christoph Hellwig
2023-09-21 1:48 ` [PATCH 9/9] xfs: grant heads track byte counts, not LSNs Dave Chinner
2023-10-12 8:53 ` Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2022-12-20 23:22 [PATCH 0/9 v3] xfs: byte-based grant head reservation tracking Dave Chinner
2022-12-20 23:23 ` [PATCH 3/9] xfs: background AIL push targets physical space, not grant space 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 3/9] xfs: background AIL push targets physical space, not grant space Dave Chinner
2022-08-22 19:00 ` Darrick J. Wong
2022-08-23 2:01 ` Dave Chinner
2022-08-26 15:47 ` Darrick J. Wong
2022-08-26 23:49 ` Darrick J. Wong
2022-09-07 14:04 ` 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=20230921014844.582667-4-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 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.