public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 4/8] xfs: l_last_sync_lsn is really tracking AIL state
Date: Wed, 20 Jul 2022 11:18:24 +1000	[thread overview]
Message-ID: <20220720011824.GT3861211@dread.disaster.area> (raw)
In-Reply-To: <20220708015558.1134330-5-david@fromorbit.com>

On Fri, Jul 08, 2022 at 11:55:54AM +1000, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> The current implementation of xlog_assign_tail_lsn() assumes that
> when the AIL is empty, the log tail matches the LSN of the last
> written commit record. This is recorded in xlog_state_set_callback()
> as log->l_last_sync_lsn when the iclog state changes to
> XLOG_STATE_CALLBACK. This change is then immediately followed by
> running the callbacks on the iclog which then insert the log items
> into the AIL at the "commit lsn" of that checkpoint.
> 
> The "commit lsn" of the checkpoint is the LSN of the iclog that the
> commit record is place in. This is also the same iclog that the
> callback is attached to. Hence the log->l_last_sync_lsn is set to
> the same value as the commit lsn recorded for the checkpoint being
> inserted into the AIL and it effectively tracks the highest ever LSN
> that the AIL has seen.
> 
> This value is not used directly by the log. It was used to determine
> the maximum push threshold for AIL pushing to ensure we didn't set
> a push target larger than had been seen in the AIL, but the AIL now
> only needs to look at it's own internal state to set push targets.
> 
> The log itself tracks it's current head via the {current_lsn,
> current_block} tuple, so it doesn't need l_last_sync_lsn for
> tracking the head of the log.  Hence nothing actually uses
> log->l_last_sync_lsn except for the tail assignment when the AIL is
> empty.
> 
> This "highest commit LSN" really doesn't need to be tracked by the
> log - the max LSN seen by the AIL can be easily tracked by the AIL
> and it can be used to set the log tail LSN correctly when the last
> item is removed from the AIL.

Ok, there's a fundamental flaw in this patch: the AIL doesn't track
the commit record LSN of log items, it tracks the *start record LSN* of the
checkpoint.

l_last_sync_lsn is the highest commit record lsn seen by the log,
whilst ailp->ail_max_seen_lsn tracks the highest start record lsn.
The difference between the two is the size of the checkpoint, and
this means by the end of the patch the grant head space that is
tracked does not have the space used by the last checkpoint
committed removed from it.

i.e. grant head space won't go to zero even when the CIL is
empty and there are no transactions in flight - the log needs to be
covered for it to drop to the size of the last iclog written to the
log during covering operations.

This causes problems with small logs - there may be space in the log
for new reservations, but because the grant space doesn't get
decremented by a log force flushing the CIL correctly,
xlog_space_left() doesn't actually report them as free and so
reservations stall until the log is covered some 30s later. Then the
same thing happens again short while later...

Essentially, this patch needs to be reworked - l_last_sync_lsn needs
to stay, but the location that is updated at needs to change to the
CIL commit callbacks so we can update it while holding the AIL lock
and then it doesn't needs to be an atomic variable....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2022-07-20  1:28 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-08  1:55 [RFC] [PATCH 0/8] xfs: byte-base grant head reservation tracking Dave Chinner
2022-07-08  1:55 ` [PATCH 1/8] xfs: AIL doesn't need manual pushing Dave Chinner
2022-07-08  7:23   ` kernel test robot
2022-07-11  6:02   ` Christoph Hellwig
2022-07-11 23:40     ` Dave Chinner
2022-07-08  1:55 ` [PATCH 2/8] xfs: AIL targets log space, not grant space Dave Chinner
2022-07-11  6:04   ` Christoph Hellwig
2022-07-08  1:55 ` [PATCH 3/8] xfs: ensure log tail is always up to date Dave Chinner
2022-07-11  6:07   ` Christoph Hellwig
2022-07-11 23:42     ` Dave Chinner
2022-07-08  1:55 ` [PATCH 4/8] xfs: l_last_sync_lsn is really tracking AIL state Dave Chinner
2022-07-11  6:42   ` Christoph Hellwig
2022-07-11 23:47     ` Dave Chinner
2022-07-20  1:18   ` Dave Chinner [this message]
2022-07-08  1:55 ` [PATCH 5/8] xfs: track log space pinned by the AIL Dave Chinner
2022-07-11  6:54   ` Christoph Hellwig
2022-07-11 23:53     ` Dave Chinner
2022-07-08  1:55 ` [PATCH 6/8] xfs: pass the full grant head to accounting functions Dave Chinner
2022-07-08  1:55 ` [PATCH 7/8] xfs: move and xfs_trans_committed_bulk Dave Chinner
2022-07-08  7:54   ` kernel test robot
2022-07-08  9:15   ` kernel test robot
2022-07-11  6:12   ` Christoph Hellwig
2022-07-11 23:54     ` Dave Chinner
2022-07-08  1:55 ` [PATCH 8/8] xfs: grant heads track byte counts, not LSNs Dave Chinner
2022-07-11  6:59   ` Christoph Hellwig
2022-07-11 23:59     ` Dave Chinner
2022-07-12  8:28   ` [xfs] 65cf4eb83e: xfstests.xfs.011.fail kernel test robot
2022-07-12 22:24     ` 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=20220720011824.GT3861211@dread.disaster.area \
    --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