2018-06-06 02:42:14 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
2005-11-02 03:58:39 +00:00
|
|
|
* Copyright (c) 2000-2002,2005 Silicon Graphics, Inc.
|
2008-10-30 06:39:23 +00:00
|
|
|
* Copyright (c) 2008 Dave Chinner
|
2005-11-02 03:58:39 +00:00
|
|
|
* All Rights Reserved.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
#include "xfs.h"
|
2005-11-02 03:38:42 +00:00
|
|
|
#include "xfs_fs.h"
|
2019-06-29 02:25:35 +00:00
|
|
|
#include "xfs_shared.h"
|
2014-11-28 03:25:04 +00:00
|
|
|
#include "xfs_format.h"
|
2013-10-22 23:50:10 +00:00
|
|
|
#include "xfs_log_format.h"
|
|
|
|
#include "xfs_trans_resv.h"
|
2005-04-16 22:20:36 +00:00
|
|
|
#include "xfs_mount.h"
|
2013-10-22 23:50:10 +00:00
|
|
|
#include "xfs_trans.h"
|
2005-04-16 22:20:36 +00:00
|
|
|
#include "xfs_trans_priv.h"
|
2011-10-11 15:14:11 +00:00
|
|
|
#include "xfs_trace.h"
|
2017-10-31 19:04:49 +00:00
|
|
|
#include "xfs_errortag.h"
|
2005-04-16 22:20:36 +00:00
|
|
|
#include "xfs_error.h"
|
2013-10-22 23:50:10 +00:00
|
|
|
#include "xfs_log.h"
|
xfs: AIL needs asynchronous CIL forcing
The AIL pushing is stalling on log forces when it comes across
pinned items. This is happening on removal workloads where the AIL
is dominated by stale items that are removed from AIL when the
checkpoint that marks the items stale is committed to the journal.
This results is relatively few items in the AIL, but those that are
are often pinned as directories items are being removed from are
still being logged.
As a result, many push cycles through the CIL will first issue a
blocking log force to unpin the items. This can take some time to
complete, with tracing regularly showing push delays of half a
second and sometimes up into the range of several seconds. Sequences
like this aren't uncommon:
....
399.829437: xfsaild: last lsn 0x11002dd000 count 101 stuck 101 flushing 0 tout 20
<wanted 20ms, got 270ms delay>
400.099622: xfsaild: target 0x11002f3600, prev 0x11002f3600, last lsn 0x0
400.099623: xfsaild: first lsn 0x11002f3600
400.099679: xfsaild: last lsn 0x1100305000 count 16 stuck 11 flushing 0 tout 50
<wanted 50ms, got 500ms delay>
400.589348: xfsaild: target 0x110032e600, prev 0x11002f3600, last lsn 0x0
400.589349: xfsaild: first lsn 0x1100305000
400.589595: xfsaild: last lsn 0x110032e600 count 156 stuck 101 flushing 30 tout 50
<wanted 50ms, got 460ms delay>
400.950341: xfsaild: target 0x1100353000, prev 0x110032e600, last lsn 0x0
400.950343: xfsaild: first lsn 0x1100317c00
400.950436: xfsaild: last lsn 0x110033d200 count 105 stuck 101 flushing 0 tout 20
<wanted 20ms, got 200ms delay>
401.142333: xfsaild: target 0x1100361600, prev 0x1100353000, last lsn 0x0
401.142334: xfsaild: first lsn 0x110032e600
401.142535: xfsaild: last lsn 0x1100353000 count 122 stuck 101 flushing 8 tout 10
<wanted 10ms, got 10ms delay>
401.154323: xfsaild: target 0x1100361600, prev 0x1100361600, last lsn 0x1100353000
401.154328: xfsaild: first lsn 0x1100353000
401.154389: xfsaild: last lsn 0x1100353000 count 101 stuck 101 flushing 0 tout 20
<wanted 20ms, got 300ms delay>
401.451525: xfsaild: target 0x1100361600, prev 0x1100361600, last lsn 0x0
401.451526: xfsaild: first lsn 0x1100353000
401.451804: xfsaild: last lsn 0x1100377200 count 170 stuck 22 flushing 122 tout 50
<wanted 50ms, got 500ms delay>
401.933581: xfsaild: target 0x1100361600, prev 0x1100361600, last lsn 0x0
....
In each of these cases, every AIL pass saw 101 log items stuck on
the AIL (pinned) with very few other items being found. Each pass, a
log force was issued, and delay between last/first is the sleep time
+ the sync log force time.
Some of these 101 items pinned the tail of the log. The tail of the
log does slowly creep forward (first lsn), but the problem is that
the log is actually out of reservation space because it's been
running so many transactions that stale items that never reach the
AIL but consume log space. Hence we have a largely empty AIL, with
long term pins on items that pin the tail of the log that don't get
pushed frequently enough to keep log space available.
The problem is the hundreds of milliseconds that we block in the log
force pushing the CIL out to disk. The AIL should not be stalled
like this - it needs to run and flush items that are at the tail of
the log with minimal latency. What we really need to do is trigger a
log flush, but then not wait for it at all - we've already done our
waiting for stuff to complete when we backed off prior to the log
force being issued.
Even if we remove the XFS_LOG_SYNC from the xfs_log_force() call, we
still do a blocking flush of the CIL and that is what is causing the
issue. Hence we need a new interface for the CIL to trigger an
immediate background push of the CIL to get it moving faster but not
to wait on that to occur. While the CIL is pushing, the AIL can also
be pushing.
We already have an internal interface to do this -
xlog_cil_push_now() - but we need a wrapper for it to be used
externally. xlog_cil_force_seq() can easily be extended to do what
we need as it already implements the synchronous CIL push via
xlog_cil_push_now(). Add the necessary flags and "push current
sequence" semantics to xlog_cil_force_seq() and convert the AIL
pushing to use it.
One of the complexities here is that the CIL push does not guarantee
that the commit record for the CIL checkpoint is written to disk.
The current log force ensures this by submitting the current ACTIVE
iclog that the commit record was written to. We need the CIL to
actually write this commit record to disk for an async push to
ensure that the checkpoint actually makes it to disk and unpins the
pinned items in the checkpoint on completion. Hence we need to pass
down to the CIL push that we are doing an async flush so that it can
switch out the commit_iclog if necessary to get written to disk when
the commit iclog is finally released.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2021-08-11 01:00:44 +00:00
|
|
|
#include "xfs_log_priv.h"
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
#ifdef DEBUG
|
2011-04-08 02:45:07 +00:00
|
|
|
/*
|
|
|
|
* Check that the list is sorted as it should be.
|
2018-05-09 14:49:09 +00:00
|
|
|
*
|
|
|
|
* Called with the ail lock held, but we don't want to assert fail with it
|
|
|
|
* held otherwise we'll lock everything up and won't be able to debug the
|
|
|
|
* cause. Hence we sample and check the state under the AIL lock and return if
|
|
|
|
* everything is fine, otherwise we drop the lock and run the ASSERT checks.
|
|
|
|
* Asserts may not be fatal, so pick the lock back up and continue onwards.
|
2011-04-08 02:45:07 +00:00
|
|
|
*/
|
|
|
|
STATIC void
|
|
|
|
xfs_ail_check(
|
2018-05-09 14:49:09 +00:00
|
|
|
struct xfs_ail *ailp,
|
|
|
|
struct xfs_log_item *lip)
|
2020-02-26 17:37:15 +00:00
|
|
|
__must_hold(&ailp->ail_lock)
|
2011-04-08 02:45:07 +00:00
|
|
|
{
|
2018-05-09 14:49:09 +00:00
|
|
|
struct xfs_log_item *prev_lip;
|
|
|
|
struct xfs_log_item *next_lip;
|
|
|
|
xfs_lsn_t prev_lsn = NULLCOMMITLSN;
|
|
|
|
xfs_lsn_t next_lsn = NULLCOMMITLSN;
|
|
|
|
xfs_lsn_t lsn;
|
|
|
|
bool in_ail;
|
|
|
|
|
2011-04-08 02:45:07 +00:00
|
|
|
|
2018-03-07 22:59:39 +00:00
|
|
|
if (list_empty(&ailp->ail_head))
|
2011-04-08 02:45:07 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
2018-05-09 14:49:09 +00:00
|
|
|
* Sample then check the next and previous entries are valid.
|
2011-04-08 02:45:07 +00:00
|
|
|
*/
|
2018-05-09 14:49:09 +00:00
|
|
|
in_ail = test_bit(XFS_LI_IN_AIL, &lip->li_flags);
|
|
|
|
prev_lip = list_entry(lip->li_ail.prev, struct xfs_log_item, li_ail);
|
2018-03-07 22:59:39 +00:00
|
|
|
if (&prev_lip->li_ail != &ailp->ail_head)
|
2018-05-09 14:49:09 +00:00
|
|
|
prev_lsn = prev_lip->li_lsn;
|
|
|
|
next_lip = list_entry(lip->li_ail.next, struct xfs_log_item, li_ail);
|
|
|
|
if (&next_lip->li_ail != &ailp->ail_head)
|
|
|
|
next_lsn = next_lip->li_lsn;
|
|
|
|
lsn = lip->li_lsn;
|
2011-04-08 02:45:07 +00:00
|
|
|
|
2018-05-09 14:49:09 +00:00
|
|
|
if (in_ail &&
|
|
|
|
(prev_lsn == NULLCOMMITLSN || XFS_LSN_CMP(prev_lsn, lsn) <= 0) &&
|
|
|
|
(next_lsn == NULLCOMMITLSN || XFS_LSN_CMP(next_lsn, lsn) >= 0))
|
|
|
|
return;
|
2011-04-08 02:45:07 +00:00
|
|
|
|
2018-05-09 14:49:09 +00:00
|
|
|
spin_unlock(&ailp->ail_lock);
|
|
|
|
ASSERT(in_ail);
|
|
|
|
ASSERT(prev_lsn == NULLCOMMITLSN || XFS_LSN_CMP(prev_lsn, lsn) <= 0);
|
|
|
|
ASSERT(next_lsn == NULLCOMMITLSN || XFS_LSN_CMP(next_lsn, lsn) >= 0);
|
|
|
|
spin_lock(&ailp->ail_lock);
|
2011-04-08 02:45:07 +00:00
|
|
|
}
|
|
|
|
#else /* !DEBUG */
|
2008-02-05 01:13:38 +00:00
|
|
|
#define xfs_ail_check(a,l)
|
2005-04-16 22:20:36 +00:00
|
|
|
#endif /* DEBUG */
|
|
|
|
|
2011-04-08 02:45:07 +00:00
|
|
|
/*
|
2011-04-08 02:45:07 +00:00
|
|
|
* Return a pointer to the last item in the AIL. If the AIL is empty, then
|
|
|
|
* return NULL.
|
|
|
|
*/
|
2019-06-29 02:27:33 +00:00
|
|
|
static struct xfs_log_item *
|
2011-04-08 02:45:07 +00:00
|
|
|
xfs_ail_max(
|
|
|
|
struct xfs_ail *ailp)
|
|
|
|
{
|
2018-03-07 22:59:39 +00:00
|
|
|
if (list_empty(&ailp->ail_head))
|
2011-04-08 02:45:07 +00:00
|
|
|
return NULL;
|
|
|
|
|
2019-06-29 02:27:33 +00:00
|
|
|
return list_entry(ailp->ail_head.prev, struct xfs_log_item, li_ail);
|
2011-04-08 02:45:07 +00:00
|
|
|
}
|
|
|
|
|
2011-04-08 02:45:07 +00:00
|
|
|
/*
|
|
|
|
* Return a pointer to the item which follows the given item in the AIL. If
|
|
|
|
* the given item is the last item in the list, then return NULL.
|
|
|
|
*/
|
2019-06-29 02:27:33 +00:00
|
|
|
static struct xfs_log_item *
|
2011-04-08 02:45:07 +00:00
|
|
|
xfs_ail_next(
|
2019-06-29 02:27:33 +00:00
|
|
|
struct xfs_ail *ailp,
|
|
|
|
struct xfs_log_item *lip)
|
2011-04-08 02:45:07 +00:00
|
|
|
{
|
2018-03-07 22:59:39 +00:00
|
|
|
if (lip->li_ail.next == &ailp->ail_head)
|
2011-04-08 02:45:07 +00:00
|
|
|
return NULL;
|
|
|
|
|
2019-06-29 02:27:33 +00:00
|
|
|
return list_first_entry(&lip->li_ail, struct xfs_log_item, li_ail);
|
2011-04-08 02:45:07 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/*
|
2011-04-08 02:45:07 +00:00
|
|
|
* This is called by the log manager code to determine the LSN of the tail of
|
|
|
|
* the log. This is exactly the LSN of the first item in the AIL. If the AIL
|
|
|
|
* is empty, then this function returns 0.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2011-04-08 02:45:07 +00:00
|
|
|
* We need the AIL lock in order to get a coherent read of the lsn of the last
|
|
|
|
* item in the AIL.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2020-03-25 03:10:29 +00:00
|
|
|
static xfs_lsn_t
|
|
|
|
__xfs_ail_min_lsn(
|
|
|
|
struct xfs_ail *ailp)
|
|
|
|
{
|
|
|
|
struct xfs_log_item *lip = xfs_ail_min(ailp);
|
|
|
|
|
|
|
|
if (lip)
|
|
|
|
return lip->li_lsn;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
xfs_lsn_t
|
2011-04-08 02:45:07 +00:00
|
|
|
xfs_ail_min_lsn(
|
2019-06-29 02:27:33 +00:00
|
|
|
struct xfs_ail *ailp)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2020-03-25 03:10:29 +00:00
|
|
|
xfs_lsn_t lsn;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2018-03-07 22:59:39 +00:00
|
|
|
spin_lock(&ailp->ail_lock);
|
2020-03-25 03:10:29 +00:00
|
|
|
lsn = __xfs_ail_min_lsn(ailp);
|
2018-03-07 22:59:39 +00:00
|
|
|
spin_unlock(&ailp->ail_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
return lsn;
|
|
|
|
}
|
|
|
|
|
2011-04-08 02:45:07 +00:00
|
|
|
/*
|
|
|
|
* Return the maximum lsn held in the AIL, or zero if the AIL is empty.
|
|
|
|
*/
|
|
|
|
static xfs_lsn_t
|
|
|
|
xfs_ail_max_lsn(
|
2019-06-29 02:27:33 +00:00
|
|
|
struct xfs_ail *ailp)
|
2011-04-08 02:45:07 +00:00
|
|
|
{
|
2019-06-29 02:27:33 +00:00
|
|
|
xfs_lsn_t lsn = 0;
|
|
|
|
struct xfs_log_item *lip;
|
2011-04-08 02:45:07 +00:00
|
|
|
|
2018-03-07 22:59:39 +00:00
|
|
|
spin_lock(&ailp->ail_lock);
|
2011-04-08 02:45:07 +00:00
|
|
|
lip = xfs_ail_max(ailp);
|
|
|
|
if (lip)
|
|
|
|
lsn = lip->li_lsn;
|
2018-03-07 22:59:39 +00:00
|
|
|
spin_unlock(&ailp->ail_lock);
|
2011-04-08 02:45:07 +00:00
|
|
|
|
|
|
|
return lsn;
|
|
|
|
}
|
|
|
|
|
2008-10-30 06:38:39 +00:00
|
|
|
/*
|
2011-07-18 03:40:18 +00:00
|
|
|
* The cursor keeps track of where our current traversal is up to by tracking
|
|
|
|
* the next item in the list for us. However, for this to be safe, removing an
|
|
|
|
* object from the AIL needs to invalidate any cursor that points to it. hence
|
|
|
|
* the traversal cursor needs to be linked to the struct xfs_ail so that
|
|
|
|
* deletion can search all the active cursors for invalidation.
|
2008-10-30 06:38:39 +00:00
|
|
|
*/
|
2008-10-30 06:39:00 +00:00
|
|
|
STATIC void
|
2008-10-30 06:38:39 +00:00
|
|
|
xfs_trans_ail_cursor_init(
|
|
|
|
struct xfs_ail *ailp,
|
|
|
|
struct xfs_ail_cursor *cur)
|
|
|
|
{
|
|
|
|
cur->item = NULL;
|
2018-03-07 22:59:39 +00:00
|
|
|
list_add_tail(&cur->list, &ailp->ail_cursors);
|
2008-10-30 06:38:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2011-07-18 03:40:18 +00:00
|
|
|
* Get the next item in the traversal and advance the cursor. If the cursor
|
|
|
|
* was invalidated (indicated by a lip of 1), restart the traversal.
|
2008-10-30 06:38:39 +00:00
|
|
|
*/
|
2008-10-30 06:39:00 +00:00
|
|
|
struct xfs_log_item *
|
2008-10-30 06:38:39 +00:00
|
|
|
xfs_trans_ail_cursor_next(
|
|
|
|
struct xfs_ail *ailp,
|
|
|
|
struct xfs_ail_cursor *cur)
|
|
|
|
{
|
|
|
|
struct xfs_log_item *lip = cur->item;
|
|
|
|
|
2015-06-21 23:43:32 +00:00
|
|
|
if ((uintptr_t)lip & 1)
|
2008-10-30 06:38:39 +00:00
|
|
|
lip = xfs_ail_min(ailp);
|
2011-07-18 03:40:17 +00:00
|
|
|
if (lip)
|
|
|
|
cur->item = xfs_ail_next(ailp, lip);
|
2008-10-30 06:38:39 +00:00
|
|
|
return lip;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2011-07-18 03:40:18 +00:00
|
|
|
* When the traversal is complete, we need to remove the cursor from the list
|
|
|
|
* of traversing cursors.
|
2008-10-30 06:38:39 +00:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
xfs_trans_ail_cursor_done(
|
2011-07-18 03:40:18 +00:00
|
|
|
struct xfs_ail_cursor *cur)
|
2008-10-30 06:38:39 +00:00
|
|
|
{
|
2011-07-18 03:40:18 +00:00
|
|
|
cur->item = NULL;
|
|
|
|
list_del_init(&cur->list);
|
2008-10-30 06:38:39 +00:00
|
|
|
}
|
|
|
|
|
2008-10-30 06:39:00 +00:00
|
|
|
/*
|
2011-07-18 03:40:18 +00:00
|
|
|
* Invalidate any cursor that is pointing to this item. This is called when an
|
|
|
|
* item is removed from the AIL. Any cursor pointing to this object is now
|
|
|
|
* invalid and the traversal needs to be terminated so it doesn't reference a
|
|
|
|
* freed object. We set the low bit of the cursor item pointer so we can
|
|
|
|
* distinguish between an invalidation and the end of the list when getting the
|
|
|
|
* next item from the cursor.
|
2008-10-30 06:39:00 +00:00
|
|
|
*/
|
|
|
|
STATIC void
|
|
|
|
xfs_trans_ail_cursor_clear(
|
|
|
|
struct xfs_ail *ailp,
|
|
|
|
struct xfs_log_item *lip)
|
|
|
|
{
|
|
|
|
struct xfs_ail_cursor *cur;
|
|
|
|
|
2018-03-07 22:59:39 +00:00
|
|
|
list_for_each_entry(cur, &ailp->ail_cursors, list) {
|
2008-10-30 06:39:00 +00:00
|
|
|
if (cur->item == lip)
|
|
|
|
cur->item = (struct xfs_log_item *)
|
2015-06-21 23:43:32 +00:00
|
|
|
((uintptr_t)cur->item | 1);
|
2008-10-30 06:39:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
/*
|
2011-07-18 03:40:17 +00:00
|
|
|
* Find the first item in the AIL with the given @lsn by searching in ascending
|
|
|
|
* LSN order and initialise the cursor to point to the next item for a
|
|
|
|
* ascending traversal. Pass a @lsn of zero to initialise the cursor to the
|
|
|
|
* first item in the AIL. Returns NULL if the list is empty.
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
*/
|
2019-06-29 02:27:33 +00:00
|
|
|
struct xfs_log_item *
|
2008-10-30 06:39:00 +00:00
|
|
|
xfs_trans_ail_cursor_first(
|
2008-10-30 06:38:39 +00:00
|
|
|
struct xfs_ail *ailp,
|
|
|
|
struct xfs_ail_cursor *cur,
|
|
|
|
xfs_lsn_t lsn)
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
{
|
2019-06-29 02:27:33 +00:00
|
|
|
struct xfs_log_item *lip;
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
|
2008-10-30 06:39:00 +00:00
|
|
|
xfs_trans_ail_cursor_init(ailp, cur);
|
2011-07-18 03:40:17 +00:00
|
|
|
|
|
|
|
if (lsn == 0) {
|
|
|
|
lip = xfs_ail_min(ailp);
|
2008-10-30 06:39:00 +00:00
|
|
|
goto out;
|
2011-07-18 03:40:17 +00:00
|
|
|
}
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
|
2018-03-07 22:59:39 +00:00
|
|
|
list_for_each_entry(lip, &ailp->ail_head, li_ail) {
|
2008-10-30 06:39:00 +00:00
|
|
|
if (XFS_LSN_CMP(lip->li_lsn, lsn) >= 0)
|
2008-10-30 07:26:51 +00:00
|
|
|
goto out;
|
2008-03-27 06:58:27 +00:00
|
|
|
}
|
2011-07-18 03:40:17 +00:00
|
|
|
return NULL;
|
|
|
|
|
2008-10-30 06:39:00 +00:00
|
|
|
out:
|
2011-07-18 03:40:17 +00:00
|
|
|
if (lip)
|
|
|
|
cur->item = xfs_ail_next(ailp, lip);
|
2008-10-30 06:39:00 +00:00
|
|
|
return lip;
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
}
|
|
|
|
|
2011-07-18 03:40:16 +00:00
|
|
|
static struct xfs_log_item *
|
|
|
|
__xfs_trans_ail_cursor_last(
|
|
|
|
struct xfs_ail *ailp,
|
|
|
|
xfs_lsn_t lsn)
|
|
|
|
{
|
2019-06-29 02:27:33 +00:00
|
|
|
struct xfs_log_item *lip;
|
2011-07-18 03:40:16 +00:00
|
|
|
|
2018-03-07 22:59:39 +00:00
|
|
|
list_for_each_entry_reverse(lip, &ailp->ail_head, li_ail) {
|
2011-07-18 03:40:16 +00:00
|
|
|
if (XFS_LSN_CMP(lip->li_lsn, lsn) <= 0)
|
|
|
|
return lip;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2011-07-18 03:40:17 +00:00
|
|
|
* Find the last item in the AIL with the given @lsn by searching in descending
|
|
|
|
* LSN order and initialise the cursor to point to that item. If there is no
|
|
|
|
* item with the value of @lsn, then it sets the cursor to the last item with an
|
|
|
|
* LSN lower than @lsn. Returns NULL if the list is empty.
|
2011-07-18 03:40:16 +00:00
|
|
|
*/
|
|
|
|
struct xfs_log_item *
|
|
|
|
xfs_trans_ail_cursor_last(
|
|
|
|
struct xfs_ail *ailp,
|
|
|
|
struct xfs_ail_cursor *cur,
|
|
|
|
xfs_lsn_t lsn)
|
|
|
|
{
|
|
|
|
xfs_trans_ail_cursor_init(ailp, cur);
|
|
|
|
cur->item = __xfs_trans_ail_cursor_last(ailp, lsn);
|
|
|
|
return cur->item;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2011-07-18 03:40:17 +00:00
|
|
|
* Splice the log item list into the AIL at the given LSN. We splice to the
|
2011-07-18 03:40:16 +00:00
|
|
|
* tail of the given LSN to maintain insert order for push traversals. The
|
|
|
|
* cursor is optional, allowing repeated updates to the same LSN to avoid
|
2011-07-22 16:04:41 +00:00
|
|
|
* repeated traversals. This should not be called with an empty list.
|
2011-04-08 02:45:07 +00:00
|
|
|
*/
|
|
|
|
static void
|
|
|
|
xfs_ail_splice(
|
2011-07-18 03:40:16 +00:00
|
|
|
struct xfs_ail *ailp,
|
|
|
|
struct xfs_ail_cursor *cur,
|
|
|
|
struct list_head *list,
|
|
|
|
xfs_lsn_t lsn)
|
2011-04-08 02:45:07 +00:00
|
|
|
{
|
2011-07-22 16:04:41 +00:00
|
|
|
struct xfs_log_item *lip;
|
|
|
|
|
|
|
|
ASSERT(!list_empty(list));
|
2011-04-08 02:45:07 +00:00
|
|
|
|
2011-07-18 03:40:16 +00:00
|
|
|
/*
|
2011-07-22 16:04:41 +00:00
|
|
|
* Use the cursor to determine the insertion point if one is
|
|
|
|
* provided. If not, or if the one we got is not valid,
|
|
|
|
* find the place in the AIL where the items belong.
|
2011-07-18 03:40:16 +00:00
|
|
|
*/
|
2011-07-22 16:04:41 +00:00
|
|
|
lip = cur ? cur->item : NULL;
|
2015-06-21 23:43:32 +00:00
|
|
|
if (!lip || (uintptr_t)lip & 1)
|
2011-07-18 03:40:16 +00:00
|
|
|
lip = __xfs_trans_ail_cursor_last(ailp, lsn);
|
|
|
|
|
2011-07-22 16:04:41 +00:00
|
|
|
/*
|
|
|
|
* If a cursor is provided, we know we're processing the AIL
|
|
|
|
* in lsn order, and future items to be spliced in will
|
|
|
|
* follow the last one being inserted now. Update the
|
|
|
|
* cursor to point to that last item, now while we have a
|
|
|
|
* reliable pointer to it.
|
|
|
|
*/
|
|
|
|
if (cur)
|
|
|
|
cur->item = list_entry(list->prev, struct xfs_log_item, li_ail);
|
2011-04-08 02:45:07 +00:00
|
|
|
|
2011-07-18 03:40:16 +00:00
|
|
|
/*
|
2011-07-22 16:04:41 +00:00
|
|
|
* Finally perform the splice. Unless the AIL was empty,
|
|
|
|
* lip points to the item in the AIL _after_ which the new
|
|
|
|
* items should go. If lip is null the AIL was empty, so
|
|
|
|
* the new items go at the head of the AIL.
|
2011-07-18 03:40:16 +00:00
|
|
|
*/
|
2011-07-22 16:04:41 +00:00
|
|
|
if (lip)
|
|
|
|
list_splice(list, &lip->li_ail);
|
|
|
|
else
|
2018-03-07 22:59:39 +00:00
|
|
|
list_splice(list, &ailp->ail_head);
|
2011-04-08 02:45:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Delete the given item from the AIL. Return a pointer to the item.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
xfs_ail_delete(
|
2019-06-29 02:27:33 +00:00
|
|
|
struct xfs_ail *ailp,
|
|
|
|
struct xfs_log_item *lip)
|
2011-04-08 02:45:07 +00:00
|
|
|
{
|
|
|
|
xfs_ail_check(ailp, lip);
|
|
|
|
list_del(&lip->li_ail);
|
|
|
|
xfs_trans_ail_cursor_clear(ailp, lip);
|
|
|
|
}
|
|
|
|
|
2020-05-06 20:25:19 +00:00
|
|
|
/*
|
|
|
|
* Requeue a failed buffer for writeback.
|
|
|
|
*
|
|
|
|
* We clear the log item failed state here as well, but we have to be careful
|
|
|
|
* about reference counts because the only active reference counts on the buffer
|
|
|
|
* may be the failed log items. Hence if we clear the log item failed state
|
|
|
|
* before queuing the buffer for IO we can release all active references to
|
|
|
|
* the buffer and free it, leading to use after free problems in
|
|
|
|
* xfs_buf_delwri_queue. It makes no difference to the buffer or log items which
|
|
|
|
* order we process them in - the buffer is locked, and we own the buffer list
|
|
|
|
* so nothing on them is going to change while we are performing this action.
|
|
|
|
*
|
|
|
|
* Hence we can safely queue the buffer for IO before we clear the failed log
|
|
|
|
* item state, therefore always having an active reference to the buffer and
|
|
|
|
* avoiding the transient zero-reference state that leads to use-after-free.
|
|
|
|
*/
|
|
|
|
static inline int
|
|
|
|
xfsaild_resubmit_item(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
struct list_head *buffer_list)
|
|
|
|
{
|
|
|
|
struct xfs_buf *bp = lip->li_buf;
|
|
|
|
|
|
|
|
if (!xfs_buf_trylock(bp))
|
|
|
|
return XFS_ITEM_LOCKED;
|
|
|
|
|
|
|
|
if (!xfs_buf_delwri_queue(bp, buffer_list)) {
|
|
|
|
xfs_buf_unlock(bp);
|
|
|
|
return XFS_ITEM_FLUSHING;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* protected by ail_lock */
|
xfs: pin inode backing buffer to the inode log item
When we dirty an inode, we are going to have to write it disk at
some point in the near future. This requires the inode cluster
backing buffer to be present in memory. Unfortunately, under severe
memory pressure we can reclaim the inode backing buffer while the
inode is dirty in memory, resulting in stalling the AIL pushing
because it has to do a read-modify-write cycle on the cluster
buffer.
When we have no memory available, the read of the cluster buffer
blocks the AIL pushing process, and this causes all sorts of issues
for memory reclaim as it requires inode writeback to make forwards
progress. Allocating a cluster buffer causes more memory pressure,
and results in more cluster buffers to be reclaimed, resulting in
more RMW cycles to be done in the AIL context and everything then
backs up on AIL progress. Only the synchronous inode cluster
writeback in the the inode reclaim code provides some level of
forwards progress guarantees that prevent OOM-killer rampages in
this situation.
Fix this by pinning the inode backing buffer to the inode log item
when the inode is first dirtied (i.e. in xfs_trans_log_inode()).
This may mean the first modification of an inode that has been held
in cache for a long time may block on a cluster buffer read, but
we can do that in transaction context and block safely until the
buffer has been allocated and read.
Once we have the cluster buffer, the inode log item takes a
reference to it, pinning it in memory, and attaches it to the log
item for future reference. This means we can always grab the cluster
buffer from the inode log item when we need it.
When the inode is finally cleaned and removed from the AIL, we can
drop the reference the inode log item holds on the cluster buffer.
Once all inodes on the cluster buffer are clean, the cluster buffer
will be unpinned and it will be available for memory reclaim to
reclaim again.
This avoids the issues with needing to do RMW cycles in the AIL
pushing context, and hence allows complete non-blocking inode
flushing to be performed by the AIL pushing context.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2020-06-29 21:49:15 +00:00
|
|
|
list_for_each_entry(lip, &bp->b_li_list, li_bio_list) {
|
|
|
|
if (bp->b_flags & _XBF_INODES)
|
|
|
|
clear_bit(XFS_LI_FAILED, &lip->li_flags);
|
|
|
|
else
|
|
|
|
xfs_clear_li_failed(lip);
|
|
|
|
}
|
2020-05-06 20:25:19 +00:00
|
|
|
|
|
|
|
xfs_buf_unlock(bp);
|
|
|
|
return XFS_ITEM_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2017-08-09 01:21:52 +00:00
|
|
|
static inline uint
|
|
|
|
xfsaild_push_item(
|
|
|
|
struct xfs_ail *ailp,
|
|
|
|
struct xfs_log_item *lip)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If log item pinning is enabled, skip the push and track the item as
|
|
|
|
* pinned. This can help induce head-behind-tail conditions.
|
|
|
|
*/
|
2022-03-17 16:09:12 +00:00
|
|
|
if (XFS_TEST_ERROR(false, ailp->ail_log->l_mp, XFS_ERRTAG_LOG_ITEM_PIN))
|
2017-08-09 01:21:52 +00:00
|
|
|
return XFS_ITEM_PINNED;
|
|
|
|
|
2019-06-29 02:27:30 +00:00
|
|
|
/*
|
|
|
|
* Consider the item pinned if a push callback is not defined so the
|
|
|
|
* caller will force the log. This should only happen for intent items
|
|
|
|
* as they are unpinned once the associated done item is committed to
|
|
|
|
* the on-disk log.
|
|
|
|
*/
|
|
|
|
if (!lip->li_ops->iop_push)
|
|
|
|
return XFS_ITEM_PINNED;
|
2020-05-06 20:25:19 +00:00
|
|
|
if (test_bit(XFS_LI_FAILED, &lip->li_flags))
|
|
|
|
return xfsaild_resubmit_item(lip, &ailp->ail_buf_list);
|
2018-03-07 22:59:39 +00:00
|
|
|
return lip->li_ops->iop_push(lip, &ailp->ail_buf_list);
|
2017-08-09 01:21:52 +00:00
|
|
|
}
|
|
|
|
|
2011-10-11 15:14:10 +00:00
|
|
|
static long
|
|
|
|
xfsaild_push(
|
|
|
|
struct xfs_ail *ailp)
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
{
|
2022-03-17 16:09:12 +00:00
|
|
|
struct xfs_mount *mp = ailp->ail_log->l_mp;
|
2011-07-18 03:40:18 +00:00
|
|
|
struct xfs_ail_cursor cur;
|
2019-06-29 02:27:33 +00:00
|
|
|
struct xfs_log_item *lip;
|
2011-05-06 02:54:05 +00:00
|
|
|
xfs_lsn_t lsn;
|
2022-11-29 01:24:42 +00:00
|
|
|
xfs_lsn_t target = NULLCOMMITLSN;
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
long tout;
|
2011-05-06 02:54:05 +00:00
|
|
|
int stuck = 0;
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
int flushing = 0;
|
2011-05-06 02:54:05 +00:00
|
|
|
int count = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-09-30 04:45:03 +00:00
|
|
|
/*
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
* If we encountered pinned items or did not finish writing out all
|
xfs: AIL needs asynchronous CIL forcing
The AIL pushing is stalling on log forces when it comes across
pinned items. This is happening on removal workloads where the AIL
is dominated by stale items that are removed from AIL when the
checkpoint that marks the items stale is committed to the journal.
This results is relatively few items in the AIL, but those that are
are often pinned as directories items are being removed from are
still being logged.
As a result, many push cycles through the CIL will first issue a
blocking log force to unpin the items. This can take some time to
complete, with tracing regularly showing push delays of half a
second and sometimes up into the range of several seconds. Sequences
like this aren't uncommon:
....
399.829437: xfsaild: last lsn 0x11002dd000 count 101 stuck 101 flushing 0 tout 20
<wanted 20ms, got 270ms delay>
400.099622: xfsaild: target 0x11002f3600, prev 0x11002f3600, last lsn 0x0
400.099623: xfsaild: first lsn 0x11002f3600
400.099679: xfsaild: last lsn 0x1100305000 count 16 stuck 11 flushing 0 tout 50
<wanted 50ms, got 500ms delay>
400.589348: xfsaild: target 0x110032e600, prev 0x11002f3600, last lsn 0x0
400.589349: xfsaild: first lsn 0x1100305000
400.589595: xfsaild: last lsn 0x110032e600 count 156 stuck 101 flushing 30 tout 50
<wanted 50ms, got 460ms delay>
400.950341: xfsaild: target 0x1100353000, prev 0x110032e600, last lsn 0x0
400.950343: xfsaild: first lsn 0x1100317c00
400.950436: xfsaild: last lsn 0x110033d200 count 105 stuck 101 flushing 0 tout 20
<wanted 20ms, got 200ms delay>
401.142333: xfsaild: target 0x1100361600, prev 0x1100353000, last lsn 0x0
401.142334: xfsaild: first lsn 0x110032e600
401.142535: xfsaild: last lsn 0x1100353000 count 122 stuck 101 flushing 8 tout 10
<wanted 10ms, got 10ms delay>
401.154323: xfsaild: target 0x1100361600, prev 0x1100361600, last lsn 0x1100353000
401.154328: xfsaild: first lsn 0x1100353000
401.154389: xfsaild: last lsn 0x1100353000 count 101 stuck 101 flushing 0 tout 20
<wanted 20ms, got 300ms delay>
401.451525: xfsaild: target 0x1100361600, prev 0x1100361600, last lsn 0x0
401.451526: xfsaild: first lsn 0x1100353000
401.451804: xfsaild: last lsn 0x1100377200 count 170 stuck 22 flushing 122 tout 50
<wanted 50ms, got 500ms delay>
401.933581: xfsaild: target 0x1100361600, prev 0x1100361600, last lsn 0x0
....
In each of these cases, every AIL pass saw 101 log items stuck on
the AIL (pinned) with very few other items being found. Each pass, a
log force was issued, and delay between last/first is the sleep time
+ the sync log force time.
Some of these 101 items pinned the tail of the log. The tail of the
log does slowly creep forward (first lsn), but the problem is that
the log is actually out of reservation space because it's been
running so many transactions that stale items that never reach the
AIL but consume log space. Hence we have a largely empty AIL, with
long term pins on items that pin the tail of the log that don't get
pushed frequently enough to keep log space available.
The problem is the hundreds of milliseconds that we block in the log
force pushing the CIL out to disk. The AIL should not be stalled
like this - it needs to run and flush items that are at the tail of
the log with minimal latency. What we really need to do is trigger a
log flush, but then not wait for it at all - we've already done our
waiting for stuff to complete when we backed off prior to the log
force being issued.
Even if we remove the XFS_LOG_SYNC from the xfs_log_force() call, we
still do a blocking flush of the CIL and that is what is causing the
issue. Hence we need a new interface for the CIL to trigger an
immediate background push of the CIL to get it moving faster but not
to wait on that to occur. While the CIL is pushing, the AIL can also
be pushing.
We already have an internal interface to do this -
xlog_cil_push_now() - but we need a wrapper for it to be used
externally. xlog_cil_force_seq() can easily be extended to do what
we need as it already implements the synchronous CIL push via
xlog_cil_push_now(). Add the necessary flags and "push current
sequence" semantics to xlog_cil_force_seq() and convert the AIL
pushing to use it.
One of the complexities here is that the CIL push does not guarantee
that the commit record for the CIL checkpoint is written to disk.
The current log force ensures this by submitting the current ACTIVE
iclog that the commit record was written to. We need the CIL to
actually write this commit record to disk for an async push to
ensure that the checkpoint actually makes it to disk and unpins the
pinned items in the checkpoint on completion. Hence we need to pass
down to the CIL push that we are doing an async flush so that it can
switch out the commit_iclog if necessary to get written to disk when
the commit iclog is finally released.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2021-08-11 01:00:44 +00:00
|
|
|
* buffers the last time we ran, force a background CIL push to get the
|
|
|
|
* items unpinned in the near future. We do not wait on the CIL push as
|
|
|
|
* that could stall us for seconds if there is enough background IO
|
|
|
|
* load. Stalling for that long when the tail of the log is pinned and
|
|
|
|
* needs flushing will hard stop the transaction subsystem when log
|
|
|
|
* space runs out.
|
2011-09-30 04:45:03 +00:00
|
|
|
*/
|
2018-03-07 22:59:39 +00:00
|
|
|
if (ailp->ail_log_flush && ailp->ail_last_pushed_lsn == 0 &&
|
|
|
|
(!list_empty_careful(&ailp->ail_buf_list) ||
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
xfs_ail_min_lsn(ailp))) {
|
2018-03-07 22:59:39 +00:00
|
|
|
ailp->ail_log_flush = 0;
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
|
2015-10-12 07:21:22 +00:00
|
|
|
XFS_STATS_INC(mp, xs_push_ail_flush);
|
2022-03-17 16:09:12 +00:00
|
|
|
xlog_cil_flush(ailp->ail_log);
|
2011-09-30 04:45:03 +00:00
|
|
|
}
|
|
|
|
|
2018-03-07 22:59:39 +00:00
|
|
|
spin_lock(&ailp->ail_lock);
|
2012-06-28 10:52:56 +00:00
|
|
|
|
xfs: xfs_ail_push_all_sync() stalls when racing with updates
xfs_ail_push_all_sync() has a loop like this:
while max_ail_lsn {
prepare_to_wait(ail_empty)
target = max_ail_lsn
wake_up(ail_task);
schedule()
}
Which is designed to sleep until the AIL is emptied. When
xfs_ail_update_finish() moves the tail of the log, it does:
if (list_empty(&ailp->ail_head))
wake_up_all(&ailp->ail_empty);
So it will only wake up the sync push waiter when the AIL goes
empty. If, by the time the push waiter has woken, the AIL has more
in it, it will reset the target, wake the push task and go back to
sleep.
The problem here is that if the AIL is having items added to it
when xfs_ail_push_all_sync() is called, then they may get inserted
into the AIL at a LSN higher than the target LSN. At this point,
xfsaild_push() will see that the target is X, the item LSNs are
(X+N) and skip over them, hence never pushing the out.
The result of this the AIL will not get emptied by the AIL push
thread, hence xfs_ail_finish_update() will never see the AIL being
empty even if it moves the tail. Hence xfs_ail_push_all_sync() never
gets woken and hence cannot update the push target to capture the
items beyond the current target on the LSN.
This is a TOCTOU type of issue so the way to avoid it is to not
use the push target at all for sync pushes. We know that a sync push
is being requested by the fact the ail_empty wait queue is active,
hence the xfsaild can just set the target to max_ail_lsn on every
push that we see the wait queue active. Hence we no longer will
leave items on the AIL that are beyond the LSN sampled at the start
of a sync push.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Chandan Babu R <chandan.babu@oracle.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2022-03-17 16:09:11 +00:00
|
|
|
/*
|
|
|
|
* If we have a sync push waiter, we always have to push till the AIL is
|
|
|
|
* empty. Update the target to point to the end of the AIL so that
|
|
|
|
* capture updates that occur after the sync push waiter has gone to
|
|
|
|
* sleep.
|
|
|
|
*/
|
|
|
|
if (waitqueue_active(&ailp->ail_empty)) {
|
|
|
|
lip = xfs_ail_max(ailp);
|
|
|
|
if (lip)
|
|
|
|
target = lip->li_lsn;
|
|
|
|
} else {
|
|
|
|
/* barrier matches the ail_target update in xfs_ail_push() */
|
|
|
|
smp_rmb();
|
|
|
|
target = ailp->ail_target;
|
|
|
|
ailp->ail_target_prev = target;
|
|
|
|
}
|
2012-06-28 10:52:56 +00:00
|
|
|
|
2020-07-16 14:39:29 +00:00
|
|
|
/* we're done if the AIL is empty or our push has reached the end */
|
2018-03-07 22:59:39 +00:00
|
|
|
lip = xfs_trans_ail_cursor_first(ailp, &cur, ailp->ail_last_pushed_lsn);
|
2020-07-16 14:39:29 +00:00
|
|
|
if (!lip)
|
2011-05-06 02:54:05 +00:00
|
|
|
goto out_done;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2015-10-12 07:21:22 +00:00
|
|
|
XFS_STATS_INC(mp, xs_push_ail);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2022-11-29 01:24:42 +00:00
|
|
|
ASSERT(target != NULLCOMMITLSN);
|
|
|
|
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
lsn = lip->li_lsn;
|
2011-05-06 02:54:06 +00:00
|
|
|
while ((XFS_LSN_CMP(lip->li_lsn, target) <= 0)) {
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
int lock_result;
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
2013-08-28 11:12:03 +00:00
|
|
|
* Note that iop_push may unlock and reacquire the AIL lock. We
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
* rely on the AIL cursor implementation to be able to deal with
|
|
|
|
* the dropped lock.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2017-08-09 01:21:52 +00:00
|
|
|
lock_result = xfsaild_push_item(ailp, lip);
|
2005-04-16 22:20:36 +00:00
|
|
|
switch (lock_result) {
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
case XFS_ITEM_SUCCESS:
|
2015-10-12 07:21:22 +00:00
|
|
|
XFS_STATS_INC(mp, xs_push_ail_success);
|
2011-10-11 15:14:11 +00:00
|
|
|
trace_xfs_ail_push(lip);
|
|
|
|
|
2018-03-07 22:59:39 +00:00
|
|
|
ailp->ail_last_pushed_lsn = lsn;
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
|
|
|
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
case XFS_ITEM_FLUSHING:
|
|
|
|
/*
|
2019-11-07 21:24:52 +00:00
|
|
|
* The item or its backing buffer is already being
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
* flushed. The typical reason for that is that an
|
|
|
|
* inode buffer is locked because we already pushed the
|
|
|
|
* updates to it as part of inode clustering.
|
|
|
|
*
|
2020-08-05 15:49:58 +00:00
|
|
|
* We do not want to stop flushing just because lots
|
2019-11-07 21:24:52 +00:00
|
|
|
* of items are already being flushed, but we need to
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
* re-try the flushing relatively soon if most of the
|
2019-11-07 21:24:52 +00:00
|
|
|
* AIL is being flushed.
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
*/
|
2015-10-12 07:21:22 +00:00
|
|
|
XFS_STATS_INC(mp, xs_push_ail_flushing);
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
trace_xfs_ail_flushing(lip);
|
|
|
|
|
|
|
|
flushing++;
|
2018-03-07 22:59:39 +00:00
|
|
|
ailp->ail_last_pushed_lsn = lsn;
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
|
|
|
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
case XFS_ITEM_PINNED:
|
2015-10-12 07:21:22 +00:00
|
|
|
XFS_STATS_INC(mp, xs_push_ail_pinned);
|
2011-10-11 15:14:11 +00:00
|
|
|
trace_xfs_ail_pinned(lip);
|
|
|
|
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
stuck++;
|
2018-03-07 22:59:39 +00:00
|
|
|
ailp->ail_log_flush++;
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
case XFS_ITEM_LOCKED:
|
2015-10-12 07:21:22 +00:00
|
|
|
XFS_STATS_INC(mp, xs_push_ail_locked);
|
2011-10-11 15:14:11 +00:00
|
|
|
trace_xfs_ail_locked(lip);
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
stuck++;
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
default:
|
2005-04-16 22:20:36 +00:00
|
|
|
ASSERT(0);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
count++;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
/*
|
|
|
|
* Are there too many items we can't do anything with?
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
*
|
2020-08-05 15:49:58 +00:00
|
|
|
* If we are skipping too many items because we can't flush
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
* them or they are already being flushed, we back off and
|
|
|
|
* given them time to complete whatever operation is being
|
|
|
|
* done. i.e. remove pressure from the AIL while we can't make
|
|
|
|
* progress so traversals don't slow down further inserts and
|
|
|
|
* removals to/from the AIL.
|
|
|
|
*
|
|
|
|
* The value of 100 is an arbitrary magic number based on
|
|
|
|
* observation.
|
|
|
|
*/
|
|
|
|
if (stuck > 100)
|
|
|
|
break;
|
|
|
|
|
2011-07-18 03:40:18 +00:00
|
|
|
lip = xfs_trans_ail_cursor_next(ailp, &cur);
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
if (lip == NULL)
|
|
|
|
break;
|
|
|
|
lsn = lip->li_lsn;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2020-07-16 14:39:29 +00:00
|
|
|
|
|
|
|
out_done:
|
2014-04-14 09:06:05 +00:00
|
|
|
xfs_trans_ail_cursor_done(&cur);
|
2018-03-07 22:59:39 +00:00
|
|
|
spin_unlock(&ailp->ail_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2018-03-07 22:59:39 +00:00
|
|
|
if (xfs_buf_delwri_submit_nowait(&ailp->ail_buf_list))
|
|
|
|
ailp->ail_log_flush++;
|
2010-02-01 23:13:42 +00:00
|
|
|
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
if (!count || XFS_LSN_CMP(lsn, target) >= 0) {
|
2008-03-06 02:45:10 +00:00
|
|
|
/*
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
* We reached the target or the AIL is empty, so wait a bit
|
|
|
|
* longer for I/O to complete and remove pushed items from the
|
|
|
|
* AIL before we start the next scan from the start of the AIL.
|
2008-03-06 02:45:10 +00:00
|
|
|
*/
|
2010-01-11 11:49:58 +00:00
|
|
|
tout = 50;
|
2018-03-07 22:59:39 +00:00
|
|
|
ailp->ail_last_pushed_lsn = 0;
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
} else if (((stuck + flushing) * 100) / count > 90) {
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
/*
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
* Either there is a lot of contention on the AIL or we are
|
|
|
|
* stuck due to operations in progress. "Stuck" in this case
|
|
|
|
* is defined as >90% of the items we tried to push were stuck.
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
*
|
|
|
|
* Backoff a bit more to allow some I/O to complete before
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
* restarting from the start of the AIL. This prevents us from
|
|
|
|
* spinning on the same items, and if they are pinned will all
|
|
|
|
* the restart to issue a log force to unpin the stuck items.
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
*/
|
2010-01-11 11:49:58 +00:00
|
|
|
tout = 20;
|
2018-03-07 22:59:39 +00:00
|
|
|
ailp->ail_last_pushed_lsn = 0;
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Assume we have more work to do in a short while.
|
|
|
|
*/
|
|
|
|
tout = 10;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2011-04-08 02:45:07 +00:00
|
|
|
|
2011-10-11 15:14:10 +00:00
|
|
|
return tout;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
xfsaild(
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
struct xfs_ail *ailp = data;
|
|
|
|
long tout = 0; /* milliseconds */
|
2020-03-10 15:57:27 +00:00
|
|
|
unsigned int noreclaim_flag;
|
2011-10-11 15:14:10 +00:00
|
|
|
|
2020-03-10 15:57:27 +00:00
|
|
|
noreclaim_flag = memalloc_noreclaim_save();
|
2016-02-08 03:59:07 +00:00
|
|
|
set_freezable();
|
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 05:58:39 +00:00
|
|
|
|
2017-10-17 21:16:28 +00:00
|
|
|
while (1) {
|
2011-10-11 15:14:10 +00:00
|
|
|
if (tout && tout <= 20)
|
freezer,sched: Rewrite core freezer logic
Rewrite the core freezer to behave better wrt thawing and be simpler
in general.
By replacing PF_FROZEN with TASK_FROZEN, a special block state, it is
ensured frozen tasks stay frozen until thawed and don't randomly wake
up early, as is currently possible.
As such, it does away with PF_FROZEN and PF_FREEZER_SKIP, freeing up
two PF_flags (yay!).
Specifically; the current scheme works a little like:
freezer_do_not_count();
schedule();
freezer_count();
And either the task is blocked, or it lands in try_to_freezer()
through freezer_count(). Now, when it is blocked, the freezer
considers it frozen and continues.
However, on thawing, once pm_freezing is cleared, freezer_count()
stops working, and any random/spurious wakeup will let a task run
before its time.
That is, thawing tries to thaw things in explicit order; kernel
threads and workqueues before doing bringing SMP back before userspace
etc.. However due to the above mentioned races it is entirely possible
for userspace tasks to thaw (by accident) before SMP is back.
This can be a fatal problem in asymmetric ISA architectures (eg ARMv9)
where the userspace task requires a special CPU to run.
As said; replace this with a special task state TASK_FROZEN and add
the following state transitions:
TASK_FREEZABLE -> TASK_FROZEN
__TASK_STOPPED -> TASK_FROZEN
__TASK_TRACED -> TASK_FROZEN
The new TASK_FREEZABLE can be set on any state part of TASK_NORMAL
(IOW. TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE) -- any such state
is already required to deal with spurious wakeups and the freezer
causes one such when thawing the task (since the original state is
lost).
The special __TASK_{STOPPED,TRACED} states *can* be restored since
their canonical state is in ->jobctl.
With this, frozen tasks need an explicit TASK_FROZEN wakeup and are
free of undue (early / spurious) wakeups.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20220822114649.055452969@infradead.org
2022-08-22 11:18:22 +00:00
|
|
|
set_current_state(TASK_KILLABLE|TASK_FREEZABLE);
|
2011-10-11 15:14:10 +00:00
|
|
|
else
|
freezer,sched: Rewrite core freezer logic
Rewrite the core freezer to behave better wrt thawing and be simpler
in general.
By replacing PF_FROZEN with TASK_FROZEN, a special block state, it is
ensured frozen tasks stay frozen until thawed and don't randomly wake
up early, as is currently possible.
As such, it does away with PF_FROZEN and PF_FREEZER_SKIP, freeing up
two PF_flags (yay!).
Specifically; the current scheme works a little like:
freezer_do_not_count();
schedule();
freezer_count();
And either the task is blocked, or it lands in try_to_freezer()
through freezer_count(). Now, when it is blocked, the freezer
considers it frozen and continues.
However, on thawing, once pm_freezing is cleared, freezer_count()
stops working, and any random/spurious wakeup will let a task run
before its time.
That is, thawing tries to thaw things in explicit order; kernel
threads and workqueues before doing bringing SMP back before userspace
etc.. However due to the above mentioned races it is entirely possible
for userspace tasks to thaw (by accident) before SMP is back.
This can be a fatal problem in asymmetric ISA architectures (eg ARMv9)
where the userspace task requires a special CPU to run.
As said; replace this with a special task state TASK_FROZEN and add
the following state transitions:
TASK_FREEZABLE -> TASK_FROZEN
__TASK_STOPPED -> TASK_FROZEN
__TASK_TRACED -> TASK_FROZEN
The new TASK_FREEZABLE can be set on any state part of TASK_NORMAL
(IOW. TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE) -- any such state
is already required to deal with spurious wakeups and the freezer
causes one such when thawing the task (since the original state is
lost).
The special __TASK_{STOPPED,TRACED} states *can* be restored since
their canonical state is in ->jobctl.
With this, frozen tasks need an explicit TASK_FROZEN wakeup and are
free of undue (early / spurious) wakeups.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20220822114649.055452969@infradead.org
2022-08-22 11:18:22 +00:00
|
|
|
set_current_state(TASK_INTERRUPTIBLE|TASK_FREEZABLE);
|
2017-10-17 21:16:28 +00:00
|
|
|
|
|
|
|
/*
|
xfs: clear ail delwri queued bufs on unmount of shutdown fs
In the typical unmount case, the AIL is forced out by the unmount
sequence before the xfsaild task is stopped. Since AIL items are
removed on writeback completion, this means that the AIL
->ail_buf_list delwri queue has been drained. This is not always
true in the shutdown case, however.
It's possible for buffers to sit on a delwri queue for a period of
time across submission attempts if said items are locked or have
been relogged and pinned since first added to the queue. If the
attempt to log such an item results in a log I/O error, the error
processing can shutdown the fs, remove the item from the AIL, stale
the buffer (dropping the LRU reference) and clear its delwri queue
state. The latter bit means the buffer will be released from a
delwri queue on the next submission attempt, but this might never
occur if the filesystem has shutdown and the AIL is empty.
This means that such buffers are held indefinitely by the AIL delwri
queue across destruction of the AIL. Aside from being a memory leak,
these buffers can also hold references to in-core perag structures.
The latter problem manifests as a generic/475 failure, reproducing
the following asserts at unmount time:
XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0,
file: fs/xfs/xfs_mount.c, line: 151
XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0,
file: fs/xfs/xfs_mount.c, line: 132
To prevent this problem, clear the AIL delwri queue as a final step
before xfsaild() exit. The !empty state should never occur in the
normal case, so add an assert to catch unexpected problems going
forward.
[dgc: add comment explaining need for xfs_buf_delwri_cancel() after
calling xfs_buf_delwri_submit_nowait().]
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-10-18 06:21:49 +00:00
|
|
|
* Check kthread_should_stop() after we set the task state to
|
|
|
|
* guarantee that we either see the stop bit and exit or the
|
|
|
|
* task state is reset to runnable such that it's not scheduled
|
|
|
|
* out indefinitely and detects the stop bit at next iteration.
|
2017-10-17 21:16:28 +00:00
|
|
|
* A memory barrier is included in above task state set to
|
|
|
|
* serialize again kthread_stop().
|
|
|
|
*/
|
|
|
|
if (kthread_should_stop()) {
|
|
|
|
__set_current_state(TASK_RUNNING);
|
xfs: clear ail delwri queued bufs on unmount of shutdown fs
In the typical unmount case, the AIL is forced out by the unmount
sequence before the xfsaild task is stopped. Since AIL items are
removed on writeback completion, this means that the AIL
->ail_buf_list delwri queue has been drained. This is not always
true in the shutdown case, however.
It's possible for buffers to sit on a delwri queue for a period of
time across submission attempts if said items are locked or have
been relogged and pinned since first added to the queue. If the
attempt to log such an item results in a log I/O error, the error
processing can shutdown the fs, remove the item from the AIL, stale
the buffer (dropping the LRU reference) and clear its delwri queue
state. The latter bit means the buffer will be released from a
delwri queue on the next submission attempt, but this might never
occur if the filesystem has shutdown and the AIL is empty.
This means that such buffers are held indefinitely by the AIL delwri
queue across destruction of the AIL. Aside from being a memory leak,
these buffers can also hold references to in-core perag structures.
The latter problem manifests as a generic/475 failure, reproducing
the following asserts at unmount time:
XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0,
file: fs/xfs/xfs_mount.c, line: 151
XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0,
file: fs/xfs/xfs_mount.c, line: 132
To prevent this problem, clear the AIL delwri queue as a final step
before xfsaild() exit. The !empty state should never occur in the
normal case, so add an assert to catch unexpected problems going
forward.
[dgc: add comment explaining need for xfs_buf_delwri_cancel() after
calling xfs_buf_delwri_submit_nowait().]
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-10-18 06:21:49 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The caller forces out the AIL before stopping the
|
|
|
|
* thread in the common case, which means the delwri
|
|
|
|
* queue is drained. In the shutdown case, the queue may
|
|
|
|
* still hold relogged buffers that haven't been
|
|
|
|
* submitted because they were pinned since added to the
|
|
|
|
* queue.
|
|
|
|
*
|
|
|
|
* Log I/O error processing stales the underlying buffer
|
|
|
|
* and clears the delwri state, expecting the buf to be
|
|
|
|
* removed on the next submission attempt. That won't
|
|
|
|
* happen if we're shutting down, so this is the last
|
|
|
|
* opportunity to release such buffers from the queue.
|
|
|
|
*/
|
|
|
|
ASSERT(list_empty(&ailp->ail_buf_list) ||
|
2022-03-17 16:09:12 +00:00
|
|
|
xlog_is_shutdown(ailp->ail_log));
|
xfs: clear ail delwri queued bufs on unmount of shutdown fs
In the typical unmount case, the AIL is forced out by the unmount
sequence before the xfsaild task is stopped. Since AIL items are
removed on writeback completion, this means that the AIL
->ail_buf_list delwri queue has been drained. This is not always
true in the shutdown case, however.
It's possible for buffers to sit on a delwri queue for a period of
time across submission attempts if said items are locked or have
been relogged and pinned since first added to the queue. If the
attempt to log such an item results in a log I/O error, the error
processing can shutdown the fs, remove the item from the AIL, stale
the buffer (dropping the LRU reference) and clear its delwri queue
state. The latter bit means the buffer will be released from a
delwri queue on the next submission attempt, but this might never
occur if the filesystem has shutdown and the AIL is empty.
This means that such buffers are held indefinitely by the AIL delwri
queue across destruction of the AIL. Aside from being a memory leak,
these buffers can also hold references to in-core perag structures.
The latter problem manifests as a generic/475 failure, reproducing
the following asserts at unmount time:
XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0,
file: fs/xfs/xfs_mount.c, line: 151
XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0,
file: fs/xfs/xfs_mount.c, line: 132
To prevent this problem, clear the AIL delwri queue as a final step
before xfsaild() exit. The !empty state should never occur in the
normal case, so add an assert to catch unexpected problems going
forward.
[dgc: add comment explaining need for xfs_buf_delwri_cancel() after
calling xfs_buf_delwri_submit_nowait().]
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-10-18 06:21:49 +00:00
|
|
|
xfs_buf_delwri_cancel(&ailp->ail_buf_list);
|
2017-10-17 21:16:28 +00:00
|
|
|
break;
|
|
|
|
}
|
2012-06-28 10:52:56 +00:00
|
|
|
|
2018-03-07 22:59:39 +00:00
|
|
|
spin_lock(&ailp->ail_lock);
|
2012-06-28 10:52:56 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Idle if the AIL is empty and we are not racing with a target
|
|
|
|
* update. We check the AIL after we set the task to a sleep
|
2018-03-07 22:59:39 +00:00
|
|
|
* state to guarantee that we either catch an ail_target update
|
2012-06-28 10:52:56 +00:00
|
|
|
* or that a wake_up resets the state to TASK_RUNNING.
|
|
|
|
* Otherwise, we run the risk of sleeping indefinitely.
|
|
|
|
*
|
2018-03-07 22:59:39 +00:00
|
|
|
* The barrier matches the ail_target update in xfs_ail_push().
|
2012-06-28 10:52:56 +00:00
|
|
|
*/
|
|
|
|
smp_rmb();
|
|
|
|
if (!xfs_ail_min(ailp) &&
|
2020-07-16 14:39:29 +00:00
|
|
|
ailp->ail_target == ailp->ail_target_prev &&
|
|
|
|
list_empty(&ailp->ail_buf_list)) {
|
2018-03-07 22:59:39 +00:00
|
|
|
spin_unlock(&ailp->ail_lock);
|
freezer,sched: Rewrite core freezer logic
Rewrite the core freezer to behave better wrt thawing and be simpler
in general.
By replacing PF_FROZEN with TASK_FROZEN, a special block state, it is
ensured frozen tasks stay frozen until thawed and don't randomly wake
up early, as is currently possible.
As such, it does away with PF_FROZEN and PF_FREEZER_SKIP, freeing up
two PF_flags (yay!).
Specifically; the current scheme works a little like:
freezer_do_not_count();
schedule();
freezer_count();
And either the task is blocked, or it lands in try_to_freezer()
through freezer_count(). Now, when it is blocked, the freezer
considers it frozen and continues.
However, on thawing, once pm_freezing is cleared, freezer_count()
stops working, and any random/spurious wakeup will let a task run
before its time.
That is, thawing tries to thaw things in explicit order; kernel
threads and workqueues before doing bringing SMP back before userspace
etc.. However due to the above mentioned races it is entirely possible
for userspace tasks to thaw (by accident) before SMP is back.
This can be a fatal problem in asymmetric ISA architectures (eg ARMv9)
where the userspace task requires a special CPU to run.
As said; replace this with a special task state TASK_FROZEN and add
the following state transitions:
TASK_FREEZABLE -> TASK_FROZEN
__TASK_STOPPED -> TASK_FROZEN
__TASK_TRACED -> TASK_FROZEN
The new TASK_FREEZABLE can be set on any state part of TASK_NORMAL
(IOW. TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE) -- any such state
is already required to deal with spurious wakeups and the freezer
causes one such when thawing the task (since the original state is
lost).
The special __TASK_{STOPPED,TRACED} states *can* be restored since
their canonical state is in ->jobctl.
With this, frozen tasks need an explicit TASK_FROZEN wakeup and are
free of undue (early / spurious) wakeups.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20220822114649.055452969@infradead.org
2022-08-22 11:18:22 +00:00
|
|
|
schedule();
|
2012-06-28 10:52:56 +00:00
|
|
|
tout = 0;
|
|
|
|
continue;
|
|
|
|
}
|
2018-03-07 22:59:39 +00:00
|
|
|
spin_unlock(&ailp->ail_lock);
|
2012-06-28 10:52:56 +00:00
|
|
|
|
|
|
|
if (tout)
|
freezer,sched: Rewrite core freezer logic
Rewrite the core freezer to behave better wrt thawing and be simpler
in general.
By replacing PF_FROZEN with TASK_FROZEN, a special block state, it is
ensured frozen tasks stay frozen until thawed and don't randomly wake
up early, as is currently possible.
As such, it does away with PF_FROZEN and PF_FREEZER_SKIP, freeing up
two PF_flags (yay!).
Specifically; the current scheme works a little like:
freezer_do_not_count();
schedule();
freezer_count();
And either the task is blocked, or it lands in try_to_freezer()
through freezer_count(). Now, when it is blocked, the freezer
considers it frozen and continues.
However, on thawing, once pm_freezing is cleared, freezer_count()
stops working, and any random/spurious wakeup will let a task run
before its time.
That is, thawing tries to thaw things in explicit order; kernel
threads and workqueues before doing bringing SMP back before userspace
etc.. However due to the above mentioned races it is entirely possible
for userspace tasks to thaw (by accident) before SMP is back.
This can be a fatal problem in asymmetric ISA architectures (eg ARMv9)
where the userspace task requires a special CPU to run.
As said; replace this with a special task state TASK_FROZEN and add
the following state transitions:
TASK_FREEZABLE -> TASK_FROZEN
__TASK_STOPPED -> TASK_FROZEN
__TASK_TRACED -> TASK_FROZEN
The new TASK_FREEZABLE can be set on any state part of TASK_NORMAL
(IOW. TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE) -- any such state
is already required to deal with spurious wakeups and the freezer
causes one such when thawing the task (since the original state is
lost).
The special __TASK_{STOPPED,TRACED} states *can* be restored since
their canonical state is in ->jobctl.
With this, frozen tasks need an explicit TASK_FROZEN wakeup and are
free of undue (early / spurious) wakeups.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20220822114649.055452969@infradead.org
2022-08-22 11:18:22 +00:00
|
|
|
schedule_timeout(msecs_to_jiffies(tout));
|
2012-06-28 10:52:56 +00:00
|
|
|
|
|
|
|
__set_current_state(TASK_RUNNING);
|
2011-10-11 15:14:10 +00:00
|
|
|
|
|
|
|
try_to_freeze();
|
|
|
|
|
|
|
|
tout = xfsaild_push(ailp);
|
|
|
|
}
|
|
|
|
|
2020-03-10 15:57:27 +00:00
|
|
|
memalloc_noreclaim_restore(noreclaim_flag);
|
2011-10-11 15:14:10 +00:00
|
|
|
return 0;
|
2010-01-11 11:49:58 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-04-08 02:45:07 +00:00
|
|
|
/*
|
|
|
|
* This routine is called to move the tail of the AIL forward. It does this by
|
|
|
|
* trying to flush items in the AIL whose lsns are below the given
|
|
|
|
* threshold_lsn.
|
|
|
|
*
|
|
|
|
* The push is run asynchronously in a workqueue, which means the caller needs
|
|
|
|
* to handle waiting on the async flush for space to become available.
|
|
|
|
* We don't want to interrupt any push that is in progress, hence we only queue
|
2019-11-07 21:24:52 +00:00
|
|
|
* work if we set the pushing bit appropriately.
|
2011-04-08 02:45:07 +00:00
|
|
|
*
|
|
|
|
* We do this unlocked - we only need to know whether there is anything in the
|
|
|
|
* AIL at the time we are called. We don't need to access the contents of
|
|
|
|
* any of the objects, so the lock is not needed.
|
|
|
|
*/
|
|
|
|
void
|
2011-04-08 02:45:07 +00:00
|
|
|
xfs_ail_push(
|
2019-06-29 02:27:33 +00:00
|
|
|
struct xfs_ail *ailp,
|
|
|
|
xfs_lsn_t threshold_lsn)
|
2011-04-08 02:45:07 +00:00
|
|
|
{
|
2019-06-29 02:27:33 +00:00
|
|
|
struct xfs_log_item *lip;
|
2011-04-08 02:45:07 +00:00
|
|
|
|
|
|
|
lip = xfs_ail_min(ailp);
|
2022-03-17 16:09:12 +00:00
|
|
|
if (!lip || xlog_is_shutdown(ailp->ail_log) ||
|
2018-03-07 22:59:39 +00:00
|
|
|
XFS_LSN_CMP(threshold_lsn, ailp->ail_target) <= 0)
|
2011-04-08 02:45:07 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ensure that the new target is noticed in push code before it clears
|
|
|
|
* the XFS_AIL_PUSHING_BIT.
|
|
|
|
*/
|
|
|
|
smp_wmb();
|
2018-03-07 22:59:39 +00:00
|
|
|
xfs_trans_ail_copy_lsn(ailp, &ailp->ail_target, &threshold_lsn);
|
2011-10-11 15:14:10 +00:00
|
|
|
smp_wmb();
|
|
|
|
|
2018-03-07 22:59:39 +00:00
|
|
|
wake_up_process(ailp->ail_task);
|
2011-04-08 02:45:07 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-04-08 02:45:07 +00:00
|
|
|
/*
|
|
|
|
* Push out all items in the AIL immediately
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
xfs_ail_push_all(
|
|
|
|
struct xfs_ail *ailp)
|
|
|
|
{
|
|
|
|
xfs_lsn_t threshold_lsn = xfs_ail_max_lsn(ailp);
|
|
|
|
|
|
|
|
if (threshold_lsn)
|
|
|
|
xfs_ail_push(ailp, threshold_lsn);
|
|
|
|
}
|
|
|
|
|
2012-04-23 05:58:34 +00:00
|
|
|
/*
|
|
|
|
* Push out all items in the AIL immediately and wait until the AIL is empty.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
xfs_ail_push_all_sync(
|
|
|
|
struct xfs_ail *ailp)
|
|
|
|
{
|
|
|
|
DEFINE_WAIT(wait);
|
|
|
|
|
2018-03-07 22:59:39 +00:00
|
|
|
spin_lock(&ailp->ail_lock);
|
2022-10-18 21:37:39 +00:00
|
|
|
while (xfs_ail_max(ailp) != NULL) {
|
2018-03-07 22:59:39 +00:00
|
|
|
prepare_to_wait(&ailp->ail_empty, &wait, TASK_UNINTERRUPTIBLE);
|
|
|
|
wake_up_process(ailp->ail_task);
|
|
|
|
spin_unlock(&ailp->ail_lock);
|
2012-04-23 05:58:34 +00:00
|
|
|
schedule();
|
2018-03-07 22:59:39 +00:00
|
|
|
spin_lock(&ailp->ail_lock);
|
2012-04-23 05:58:34 +00:00
|
|
|
}
|
2018-03-07 22:59:39 +00:00
|
|
|
spin_unlock(&ailp->ail_lock);
|
2012-04-23 05:58:34 +00:00
|
|
|
|
2018-03-07 22:59:39 +00:00
|
|
|
finish_wait(&ailp->ail_empty, &wait);
|
2012-04-23 05:58:34 +00:00
|
|
|
}
|
|
|
|
|
2020-03-25 03:10:29 +00:00
|
|
|
void
|
|
|
|
xfs_ail_update_finish(
|
|
|
|
struct xfs_ail *ailp,
|
2020-03-25 03:10:29 +00:00
|
|
|
xfs_lsn_t old_lsn) __releases(ailp->ail_lock)
|
2020-03-25 03:10:29 +00:00
|
|
|
{
|
2022-03-17 16:09:12 +00:00
|
|
|
struct xlog *log = ailp->ail_log;
|
2020-03-25 03:10:29 +00:00
|
|
|
|
2020-03-25 03:10:29 +00:00
|
|
|
/* if the tail lsn hasn't changed, don't do updates or wakeups. */
|
|
|
|
if (!old_lsn || old_lsn == __xfs_ail_min_lsn(ailp)) {
|
2020-03-25 03:10:29 +00:00
|
|
|
spin_unlock(&ailp->ail_lock);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2022-03-17 16:09:12 +00:00
|
|
|
if (!xlog_is_shutdown(log))
|
|
|
|
xlog_assign_tail_lsn_locked(log->l_mp);
|
2020-03-25 03:10:29 +00:00
|
|
|
|
|
|
|
if (list_empty(&ailp->ail_head))
|
|
|
|
wake_up_all(&ailp->ail_empty);
|
|
|
|
spin_unlock(&ailp->ail_lock);
|
2022-03-17 16:09:12 +00:00
|
|
|
xfs_log_space_wake(log->l_mp);
|
2020-03-25 03:10:29 +00:00
|
|
|
}
|
|
|
|
|
2010-12-20 01:02:19 +00:00
|
|
|
/*
|
|
|
|
* xfs_trans_ail_update - bulk AIL insertion operation.
|
|
|
|
*
|
|
|
|
* @xfs_trans_ail_update takes an array of log items that all need to be
|
|
|
|
* positioned at the same LSN in the AIL. If an item is not in the AIL, it will
|
|
|
|
* be added. Otherwise, it will be repositioned by removing it and re-adding
|
|
|
|
* it to the AIL. If we move the first item in the AIL, update the log tail to
|
|
|
|
* match the new minimum LSN in the AIL.
|
|
|
|
*
|
|
|
|
* This function takes the AIL lock once to execute the update operations on
|
|
|
|
* all the items in the array, and as such should not be called with the AIL
|
|
|
|
* lock held. As a result, once we have the AIL lock, we need to check each log
|
|
|
|
* item LSN to confirm it needs to be moved forward in the AIL.
|
|
|
|
*
|
|
|
|
* To optimise the insert operation, we delete all the items from the AIL in
|
|
|
|
* the first pass, moving them into a temporary list, then splice the temporary
|
|
|
|
* list into the correct position in the AIL. This avoids needing to do an
|
|
|
|
* insert operation on every item.
|
|
|
|
*
|
|
|
|
* This function must be called with the AIL lock held. The lock is dropped
|
|
|
|
* before returning.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
xfs_trans_ail_update_bulk(
|
|
|
|
struct xfs_ail *ailp,
|
2011-07-18 03:40:16 +00:00
|
|
|
struct xfs_ail_cursor *cur,
|
2010-12-20 01:02:19 +00:00
|
|
|
struct xfs_log_item **log_items,
|
|
|
|
int nr_items,
|
2018-03-07 22:59:39 +00:00
|
|
|
xfs_lsn_t lsn) __releases(ailp->ail_lock)
|
2010-12-20 01:02:19 +00:00
|
|
|
{
|
2019-06-29 02:27:33 +00:00
|
|
|
struct xfs_log_item *mlip;
|
2020-03-25 03:10:29 +00:00
|
|
|
xfs_lsn_t tail_lsn = 0;
|
2010-12-20 01:02:19 +00:00
|
|
|
int i;
|
|
|
|
LIST_HEAD(tmp);
|
|
|
|
|
2011-07-22 16:04:41 +00:00
|
|
|
ASSERT(nr_items > 0); /* Not required, but true. */
|
2010-12-20 01:02:19 +00:00
|
|
|
mlip = xfs_ail_min(ailp);
|
|
|
|
|
|
|
|
for (i = 0; i < nr_items; i++) {
|
|
|
|
struct xfs_log_item *lip = log_items[i];
|
2018-05-09 14:47:34 +00:00
|
|
|
if (test_and_set_bit(XFS_LI_IN_AIL, &lip->li_flags)) {
|
2010-12-20 01:02:19 +00:00
|
|
|
/* check if we really need to move the item */
|
|
|
|
if (XFS_LSN_CMP(lsn, lip->li_lsn) <= 0)
|
|
|
|
continue;
|
|
|
|
|
2013-11-01 04:27:18 +00:00
|
|
|
trace_xfs_ail_move(lip, lip->li_lsn, lsn);
|
2020-03-25 03:10:29 +00:00
|
|
|
if (mlip == lip && !tail_lsn)
|
|
|
|
tail_lsn = lip->li_lsn;
|
|
|
|
|
2010-12-20 01:02:19 +00:00
|
|
|
xfs_ail_delete(ailp, lip);
|
|
|
|
} else {
|
2013-11-01 04:27:18 +00:00
|
|
|
trace_xfs_ail_insert(lip, 0, lsn);
|
2010-12-20 01:02:19 +00:00
|
|
|
}
|
|
|
|
lip->li_lsn = lsn;
|
xfs: don't reverse order of items in bulk AIL insertion
XFS has strict metadata ordering requirements. One of the things it
does is maintain the commit order of items from transaction commit
through the CIL and into the AIL. That is, if a transaction logs
item A before item B in a modification, then they will be inserted
into the CIL in the order {A, B}. These items are then written into
the iclog during checkpointing in the order {A, B}. When the
checkpoint commits, they are supposed to be inserted into the AIL in
the order {A, B}, and when they are pushed from the AIL, they are
pushed in the order {A, B}.
If we crash, log recovery then replays the two items from the
checkpoint in the order {A, B}, resulting in the objects the items
apply to being queued for writeback at the end of the checkpoint
in the order {A, B}. This means recovery behaves the same way as the
runtime code.
In places, we have subtle dependencies on this ordering being
maintained. One of this place is performing intent recovery from the
log. It assumes that recovering an intent will result in a
non-intent object being the first thing that is modified in the
recovery transaction, and so when the transaction commits and the
journal flushes, the first object inserted into the AIL beyond the
intent recovery range will be a non-intent item. It uses the
transistion from intent items to non-intent items to stop the
recovery pass.
A recent log recovery issue indicated that an intent was appearing
as the first item in the AIL beyond the recovery range, hence
breaking the end of recovery detection that exists.
Tracing indicated insertion of the items into the AIL was apparently
occurring in the right order (the intent was last in the commit item
list), but the intent was appearing first in the AIL. IOWs, the
order of items in the AIL was {D,C,B,A}, not {A,B,C,D}, and bulk
insertion was reversing the order of the items in the batch of items
being inserted.
Lucky for us, all the items fed to bulk insertion have the same LSN,
so the reversal of order does not affect the log head/tail tracking
that is based on the contents of the AIL. It only impacts on code
that has implicit, subtle dependencies on object order, and AFAICT
only the intent recovery loop is impacted by it.
Make sure bulk AIL insertion does not reorder items incorrectly.
Fixes: 0e57f6a36f9b ("xfs: bulk AIL insertion during transaction commit")
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Chandan Babu R <chandan.babu@oracle.com>
2023-06-28 18:04:31 +00:00
|
|
|
list_add_tail(&lip->li_ail, &tmp);
|
2010-12-20 01:02:19 +00:00
|
|
|
}
|
|
|
|
|
2011-07-22 16:04:41 +00:00
|
|
|
if (!list_empty(&tmp))
|
|
|
|
xfs_ail_splice(ailp, cur, &tmp, lsn);
|
2010-12-20 01:02:19 +00:00
|
|
|
|
2020-03-25 03:10:29 +00:00
|
|
|
xfs_ail_update_finish(ailp, tail_lsn);
|
2020-05-01 23:00:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Insert a log item into the AIL. */
|
|
|
|
void
|
|
|
|
xfs_trans_ail_insert(
|
|
|
|
struct xfs_ail *ailp,
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
xfs_lsn_t lsn)
|
|
|
|
{
|
|
|
|
spin_lock(&ailp->ail_lock);
|
|
|
|
xfs_trans_ail_update_bulk(ailp, NULL, &lip, 1, lsn);
|
2010-12-20 01:02:19 +00:00
|
|
|
}
|
|
|
|
|
2020-03-25 03:10:29 +00:00
|
|
|
/*
|
|
|
|
* Delete one log item from the AIL.
|
|
|
|
*
|
|
|
|
* If this item was at the tail of the AIL, return the LSN of the log item so
|
|
|
|
* that we can use it to check if the LSN of the tail of the log has moved
|
|
|
|
* when finishing up the AIL delete process in xfs_ail_update_finish().
|
|
|
|
*/
|
|
|
|
xfs_lsn_t
|
2017-04-21 18:24:42 +00:00
|
|
|
xfs_ail_delete_one(
|
|
|
|
struct xfs_ail *ailp,
|
xfs: Properly retry failed inode items in case of error during buffer writeback
When a buffer has been failed during writeback, the inode items into it
are kept flush locked, and are never resubmitted due the flush lock, so,
if any buffer fails to be written, the items in AIL are never written to
disk and never unlocked.
This causes unmount operation to hang due these items flush locked in AIL,
but this also causes the items in AIL to never be written back, even when
the IO device comes back to normal.
I've been testing this patch with a DM-thin device, creating a
filesystem larger than the real device.
When writing enough data to fill the DM-thin device, XFS receives ENOSPC
errors from the device, and keep spinning on xfsaild (when 'retry
forever' configuration is set).
At this point, the filesystem can not be unmounted because of the flush locked
items in AIL, but worse, the items in AIL are never retried at all
(once xfs_inode_item_push() will skip the items that are flush locked),
even if the underlying DM-thin device is expanded to the proper size.
This patch fixes both cases, retrying any item that has been failed
previously, using the infra-structure provided by the previous patch.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2017-08-09 01:21:50 +00:00
|
|
|
struct xfs_log_item *lip)
|
2017-04-21 18:24:42 +00:00
|
|
|
{
|
|
|
|
struct xfs_log_item *mlip = xfs_ail_min(ailp);
|
2020-03-25 03:10:29 +00:00
|
|
|
xfs_lsn_t lsn = lip->li_lsn;
|
2017-04-21 18:24:42 +00:00
|
|
|
|
|
|
|
trace_xfs_ail_delete(lip, mlip->li_lsn, lip->li_lsn);
|
|
|
|
xfs_ail_delete(ailp, lip);
|
2018-05-09 14:47:34 +00:00
|
|
|
clear_bit(XFS_LI_IN_AIL, &lip->li_flags);
|
2017-04-21 18:24:42 +00:00
|
|
|
lip->li_lsn = 0;
|
|
|
|
|
2020-03-25 03:10:29 +00:00
|
|
|
if (mlip == lip)
|
|
|
|
return lsn;
|
|
|
|
return 0;
|
2017-04-21 18:24:42 +00:00
|
|
|
}
|
|
|
|
|
2010-12-20 01:03:17 +00:00
|
|
|
void
|
2017-04-21 18:24:42 +00:00
|
|
|
xfs_trans_ail_delete(
|
|
|
|
struct xfs_log_item *lip,
|
2020-03-25 03:10:29 +00:00
|
|
|
int shutdown_type)
|
2010-12-20 01:03:17 +00:00
|
|
|
{
|
2020-05-06 20:25:23 +00:00
|
|
|
struct xfs_ail *ailp = lip->li_ailp;
|
xfs: log shutdown triggers should only shut down the log
We've got a mess on our hands.
1. xfs_trans_commit() cannot cancel transactions because the mount is
shut down - that causes dirty, aborted, unlogged log items to sit
unpinned in memory and potentially get written to disk before the
log is shut down. Hence xfs_trans_commit() can only abort
transactions when xlog_is_shutdown() is true.
2. xfs_force_shutdown() is used in places to cause the current
modification to be aborted via xfs_trans_commit() because it may be
impractical or impossible to cancel the transaction directly, and
hence xfs_trans_commit() must cancel transactions when
xfs_is_shutdown() is true in this situation. But we can't do that
because of #1.
3. Log IO errors cause log shutdowns by calling xfs_force_shutdown()
to shut down the mount and then the log from log IO completion.
4. xfs_force_shutdown() can result in a log force being issued,
which has to wait for log IO completion before it will mark the log
as shut down. If #3 races with some other shutdown trigger that runs
a log force, we rely on xfs_force_shutdown() silently ignoring #3
and avoiding shutting down the log until the failed log force
completes.
5. To ensure #2 always works, we have to ensure that
xfs_force_shutdown() does not return until the the log is shut down.
But in the case of #4, this will result in a deadlock because the
log Io completion will block waiting for a log force to complete
which is blocked waiting for log IO to complete....
So the very first thing we have to do here to untangle this mess is
dissociate log shutdown triggers from mount shutdowns. We already
have xlog_forced_shutdown, which will atomically transistion to the
log a shutdown state. Due to internal asserts it cannot be called
multiple times, but was done simply because the only place that
could call it was xfs_do_force_shutdown() (i.e. the mount shutdown!)
and that could only call it once and once only. So the first thing
we do is remove the asserts.
We then convert all the internal log shutdown triggers to call
xlog_force_shutdown() directly instead of xfs_force_shutdown(). This
allows the log shutdown triggers to shut down the log without
needing to care about mount based shutdown constraints. This means
we shut down the log independently of the mount and the mount may
not notice this until it's next attempt to read or modify metadata.
At that point (e.g. xfs_trans_commit()) it will see that the log is
shutdown, error out and shutdown the mount.
To ensure that all the unmount behaviours and asserts track
correctly as a result of a log shutdown, propagate the shutdown up
to the mount if it is not already set. This keeps the mount and log
state in sync, and saves a huge amount of hassle where code fails
because of a log shutdown but only checks for mount shutdowns and
hence ends up doing the wrong thing. Cleaning up that mess is
an exercise for another day.
This enables us to address the other problems noted above in
followup patches.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2022-03-30 01:22:01 +00:00
|
|
|
struct xlog *log = ailp->ail_log;
|
2020-03-25 03:10:29 +00:00
|
|
|
xfs_lsn_t tail_lsn;
|
2010-12-20 01:03:17 +00:00
|
|
|
|
2020-05-06 20:25:23 +00:00
|
|
|
spin_lock(&ailp->ail_lock);
|
2018-05-09 14:47:34 +00:00
|
|
|
if (!test_bit(XFS_LI_IN_AIL, &lip->li_flags)) {
|
2018-03-07 22:59:39 +00:00
|
|
|
spin_unlock(&ailp->ail_lock);
|
xfs: log shutdown triggers should only shut down the log
We've got a mess on our hands.
1. xfs_trans_commit() cannot cancel transactions because the mount is
shut down - that causes dirty, aborted, unlogged log items to sit
unpinned in memory and potentially get written to disk before the
log is shut down. Hence xfs_trans_commit() can only abort
transactions when xlog_is_shutdown() is true.
2. xfs_force_shutdown() is used in places to cause the current
modification to be aborted via xfs_trans_commit() because it may be
impractical or impossible to cancel the transaction directly, and
hence xfs_trans_commit() must cancel transactions when
xfs_is_shutdown() is true in this situation. But we can't do that
because of #1.
3. Log IO errors cause log shutdowns by calling xfs_force_shutdown()
to shut down the mount and then the log from log IO completion.
4. xfs_force_shutdown() can result in a log force being issued,
which has to wait for log IO completion before it will mark the log
as shut down. If #3 races with some other shutdown trigger that runs
a log force, we rely on xfs_force_shutdown() silently ignoring #3
and avoiding shutting down the log until the failed log force
completes.
5. To ensure #2 always works, we have to ensure that
xfs_force_shutdown() does not return until the the log is shut down.
But in the case of #4, this will result in a deadlock because the
log Io completion will block waiting for a log force to complete
which is blocked waiting for log IO to complete....
So the very first thing we have to do here to untangle this mess is
dissociate log shutdown triggers from mount shutdowns. We already
have xlog_forced_shutdown, which will atomically transistion to the
log a shutdown state. Due to internal asserts it cannot be called
multiple times, but was done simply because the only place that
could call it was xfs_do_force_shutdown() (i.e. the mount shutdown!)
and that could only call it once and once only. So the first thing
we do is remove the asserts.
We then convert all the internal log shutdown triggers to call
xlog_force_shutdown() directly instead of xfs_force_shutdown(). This
allows the log shutdown triggers to shut down the log without
needing to care about mount based shutdown constraints. This means
we shut down the log independently of the mount and the mount may
not notice this until it's next attempt to read or modify metadata.
At that point (e.g. xfs_trans_commit()) it will see that the log is
shutdown, error out and shutdown the mount.
To ensure that all the unmount behaviours and asserts track
correctly as a result of a log shutdown, propagate the shutdown up
to the mount if it is not already set. This keeps the mount and log
state in sync, and saves a huge amount of hassle where code fails
because of a log shutdown but only checks for mount shutdowns and
hence ends up doing the wrong thing. Cleaning up that mess is
an exercise for another day.
This enables us to address the other problems noted above in
followup patches.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2022-03-30 01:22:01 +00:00
|
|
|
if (shutdown_type && !xlog_is_shutdown(log)) {
|
|
|
|
xfs_alert_tag(log->l_mp, XFS_PTAG_AILDELETE,
|
2017-04-21 18:24:42 +00:00
|
|
|
"%s: attempting to delete a log item that is not in the AIL",
|
|
|
|
__func__);
|
xfs: log shutdown triggers should only shut down the log
We've got a mess on our hands.
1. xfs_trans_commit() cannot cancel transactions because the mount is
shut down - that causes dirty, aborted, unlogged log items to sit
unpinned in memory and potentially get written to disk before the
log is shut down. Hence xfs_trans_commit() can only abort
transactions when xlog_is_shutdown() is true.
2. xfs_force_shutdown() is used in places to cause the current
modification to be aborted via xfs_trans_commit() because it may be
impractical or impossible to cancel the transaction directly, and
hence xfs_trans_commit() must cancel transactions when
xfs_is_shutdown() is true in this situation. But we can't do that
because of #1.
3. Log IO errors cause log shutdowns by calling xfs_force_shutdown()
to shut down the mount and then the log from log IO completion.
4. xfs_force_shutdown() can result in a log force being issued,
which has to wait for log IO completion before it will mark the log
as shut down. If #3 races with some other shutdown trigger that runs
a log force, we rely on xfs_force_shutdown() silently ignoring #3
and avoiding shutting down the log until the failed log force
completes.
5. To ensure #2 always works, we have to ensure that
xfs_force_shutdown() does not return until the the log is shut down.
But in the case of #4, this will result in a deadlock because the
log Io completion will block waiting for a log force to complete
which is blocked waiting for log IO to complete....
So the very first thing we have to do here to untangle this mess is
dissociate log shutdown triggers from mount shutdowns. We already
have xlog_forced_shutdown, which will atomically transistion to the
log a shutdown state. Due to internal asserts it cannot be called
multiple times, but was done simply because the only place that
could call it was xfs_do_force_shutdown() (i.e. the mount shutdown!)
and that could only call it once and once only. So the first thing
we do is remove the asserts.
We then convert all the internal log shutdown triggers to call
xlog_force_shutdown() directly instead of xfs_force_shutdown(). This
allows the log shutdown triggers to shut down the log without
needing to care about mount based shutdown constraints. This means
we shut down the log independently of the mount and the mount may
not notice this until it's next attempt to read or modify metadata.
At that point (e.g. xfs_trans_commit()) it will see that the log is
shutdown, error out and shutdown the mount.
To ensure that all the unmount behaviours and asserts track
correctly as a result of a log shutdown, propagate the shutdown up
to the mount if it is not already set. This keeps the mount and log
state in sync, and saves a huge amount of hassle where code fails
because of a log shutdown but only checks for mount shutdowns and
hence ends up doing the wrong thing. Cleaning up that mess is
an exercise for another day.
This enables us to address the other problems noted above in
followup patches.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
2022-03-30 01:22:01 +00:00
|
|
|
xlog_force_shutdown(log, shutdown_type);
|
2010-12-20 01:03:17 +00:00
|
|
|
}
|
2017-04-21 18:24:42 +00:00
|
|
|
return;
|
2010-12-20 01:03:17 +00:00
|
|
|
}
|
|
|
|
|
2020-05-06 20:27:04 +00:00
|
|
|
/* xfs_ail_update_finish() drops the AIL lock */
|
2020-06-29 21:49:15 +00:00
|
|
|
xfs_clear_li_failed(lip);
|
2020-03-25 03:10:29 +00:00
|
|
|
tail_lsn = xfs_ail_delete_one(ailp, lip);
|
|
|
|
xfs_ail_update_finish(ailp, tail_lsn);
|
2010-12-20 01:03:17 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
int
|
2005-04-16 22:20:36 +00:00
|
|
|
xfs_trans_ail_init(
|
|
|
|
xfs_mount_t *mp)
|
|
|
|
{
|
2008-10-30 06:38:26 +00:00
|
|
|
struct xfs_ail *ailp;
|
|
|
|
|
2024-01-15 22:59:39 +00:00
|
|
|
ailp = kzalloc(sizeof(struct xfs_ail),
|
|
|
|
GFP_KERNEL | __GFP_RETRY_MAYFAIL);
|
2008-10-30 06:38:26 +00:00
|
|
|
if (!ailp)
|
2014-06-25 04:58:08 +00:00
|
|
|
return -ENOMEM;
|
2008-10-30 06:38:26 +00:00
|
|
|
|
2022-03-17 16:09:12 +00:00
|
|
|
ailp->ail_log = mp->m_log;
|
2018-03-07 22:59:39 +00:00
|
|
|
INIT_LIST_HEAD(&ailp->ail_head);
|
|
|
|
INIT_LIST_HEAD(&ailp->ail_cursors);
|
|
|
|
spin_lock_init(&ailp->ail_lock);
|
|
|
|
INIT_LIST_HEAD(&ailp->ail_buf_list);
|
|
|
|
init_waitqueue_head(&ailp->ail_empty);
|
2011-10-11 15:14:10 +00:00
|
|
|
|
2018-03-07 22:59:39 +00:00
|
|
|
ailp->ail_task = kthread_run(xfsaild, ailp, "xfsaild/%s",
|
2022-03-17 16:09:12 +00:00
|
|
|
mp->m_super->s_id);
|
2018-03-07 22:59:39 +00:00
|
|
|
if (IS_ERR(ailp->ail_task))
|
2011-10-11 15:14:10 +00:00
|
|
|
goto out_free_ailp;
|
|
|
|
|
2008-10-30 06:38:39 +00:00
|
|
|
mp->m_ail = ailp;
|
|
|
|
return 0;
|
2011-10-11 15:14:10 +00:00
|
|
|
|
|
|
|
out_free_ailp:
|
2024-01-15 22:59:43 +00:00
|
|
|
kfree(ailp);
|
2014-06-25 04:58:08 +00:00
|
|
|
return -ENOMEM;
|
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 01:13:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
xfs_trans_ail_destroy(
|
|
|
|
xfs_mount_t *mp)
|
|
|
|
{
|
2008-10-30 06:38:26 +00:00
|
|
|
struct xfs_ail *ailp = mp->m_ail;
|
|
|
|
|
2018-03-07 22:59:39 +00:00
|
|
|
kthread_stop(ailp->ail_task);
|
2024-01-15 22:59:43 +00:00
|
|
|
kfree(ailp);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|