2005-04-16 18:20:36 -04:00
|
|
|
/*
|
2005-11-01 22:58:39 -05:00
|
|
|
* Copyright (c) 2000-2002,2005 Silicon Graphics, Inc.
|
|
|
|
* All Rights Reserved.
|
2005-04-16 18:20:36 -04:00
|
|
|
*
|
2005-11-01 22:58:39 -05:00
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License as
|
2005-04-16 18:20:36 -04:00
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*
|
2005-11-01 22:58:39 -05:00
|
|
|
* This program is distributed in the hope that it would be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
2005-04-16 18:20:36 -04:00
|
|
|
*
|
2005-11-01 22:58:39 -05:00
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write the Free Software Foundation,
|
|
|
|
* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
2005-04-16 18:20:36 -04:00
|
|
|
*/
|
|
|
|
#include "xfs.h"
|
2005-11-01 22:38:42 -05:00
|
|
|
#include "xfs_fs.h"
|
2005-04-16 18:20:36 -04:00
|
|
|
#include "xfs_types.h"
|
|
|
|
#include "xfs_log.h"
|
2005-11-01 22:38:42 -05:00
|
|
|
#include "xfs_inum.h"
|
2005-04-16 18:20:36 -04:00
|
|
|
#include "xfs_trans.h"
|
|
|
|
#include "xfs_sb.h"
|
2007-08-28 00:00:13 -04:00
|
|
|
#include "xfs_ag.h"
|
2005-04-16 18:20:36 -04:00
|
|
|
#include "xfs_dmapi.h"
|
|
|
|
#include "xfs_mount.h"
|
|
|
|
#include "xfs_trans_priv.h"
|
|
|
|
#include "xfs_error.h"
|
|
|
|
|
2008-03-27 02:58:27 -04:00
|
|
|
STATIC void xfs_ail_insert(xfs_ail_t *, xfs_log_item_t *);
|
|
|
|
STATIC xfs_log_item_t * xfs_ail_delete(xfs_ail_t *, xfs_log_item_t *);
|
|
|
|
STATIC xfs_log_item_t * xfs_ail_min(xfs_ail_t *);
|
|
|
|
STATIC xfs_log_item_t * xfs_ail_next(xfs_ail_t *, xfs_log_item_t *);
|
2005-04-16 18:20:36 -04:00
|
|
|
|
|
|
|
#ifdef DEBUG
|
2008-03-27 02:58:27 -04:00
|
|
|
STATIC void xfs_ail_check(xfs_ail_t *, xfs_log_item_t *);
|
2005-04-16 18:20:36 -04:00
|
|
|
#else
|
2008-02-04 20:13:38 -05:00
|
|
|
#define xfs_ail_check(a,l)
|
2005-04-16 18:20:36 -04:00
|
|
|
#endif /* DEBUG */
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
* We need the AIL lock in order to get a coherent read of the
|
|
|
|
* lsn of the last item in the AIL.
|
|
|
|
*/
|
|
|
|
xfs_lsn_t
|
|
|
|
xfs_trans_tail_ail(
|
|
|
|
xfs_mount_t *mp)
|
|
|
|
{
|
|
|
|
xfs_lsn_t lsn;
|
|
|
|
xfs_log_item_t *lip;
|
|
|
|
|
2007-10-11 03:36:05 -04:00
|
|
|
spin_lock(&mp->m_ail_lock);
|
2008-03-27 02:58:27 -04:00
|
|
|
lip = xfs_ail_min(&mp->m_ail);
|
2005-04-16 18:20:36 -04:00
|
|
|
if (lip == NULL) {
|
|
|
|
lsn = (xfs_lsn_t)0;
|
|
|
|
} else {
|
|
|
|
lsn = lip->li_lsn;
|
|
|
|
}
|
2007-10-11 03:36:05 -04:00
|
|
|
spin_unlock(&mp->m_ail_lock);
|
2005-04-16 18:20:36 -04:00
|
|
|
|
|
|
|
return lsn;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* xfs_trans_push_ail
|
|
|
|
*
|
[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-04 20:13:32 -05: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.
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
* the push is run asynchronously in a separate thread, so we return the tail
|
|
|
|
* of the log right now instead of the tail after the push. This means we will
|
|
|
|
* either continue right away, or we will sleep waiting on the async thread to
|
|
|
|
* do it's work.
|
|
|
|
*
|
|
|
|
* 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.
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
void
|
2005-04-16 18:20:36 -04:00
|
|
|
xfs_trans_push_ail(
|
|
|
|
xfs_mount_t *mp,
|
|
|
|
xfs_lsn_t threshold_lsn)
|
|
|
|
{
|
|
|
|
xfs_log_item_t *lip;
|
|
|
|
|
2008-03-27 02:58:27 -04:00
|
|
|
lip = xfs_ail_min(&mp->m_ail);
|
[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-04 20:13:32 -05:00
|
|
|
if (lip && !XFS_FORCED_SHUTDOWN(mp)) {
|
|
|
|
if (XFS_LSN_CMP(threshold_lsn, mp->m_ail.xa_target) > 0)
|
|
|
|
xfsaild_wakeup(mp, threshold_lsn);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return the item in the AIL with the current lsn.
|
|
|
|
* Return the current tree generation number for use
|
|
|
|
* in calls to xfs_trans_next_ail().
|
|
|
|
*/
|
|
|
|
STATIC xfs_log_item_t *
|
|
|
|
xfs_trans_first_push_ail(
|
|
|
|
xfs_mount_t *mp,
|
|
|
|
int *gen,
|
|
|
|
xfs_lsn_t lsn)
|
|
|
|
{
|
|
|
|
xfs_log_item_t *lip;
|
|
|
|
|
2008-03-27 02:58:27 -04:00
|
|
|
lip = xfs_ail_min(&mp->m_ail);
|
[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-04 20:13:32 -05:00
|
|
|
*gen = (int)mp->m_ail.xa_gen;
|
|
|
|
if (lsn == 0)
|
|
|
|
return lip;
|
|
|
|
|
2008-03-27 02:58:27 -04:00
|
|
|
list_for_each_entry(lip, &mp->m_ail.xa_ail, li_ail) {
|
|
|
|
if (XFS_LSN_CMP(lip->li_lsn, lsn) >= 0)
|
|
|
|
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-04 20:13:32 -05:00
|
|
|
|
2008-03-27 02:58:27 -04:00
|
|
|
return NULL;
|
[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-04 20:13:32 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Function that does the work of pushing on the AIL
|
|
|
|
*/
|
|
|
|
long
|
|
|
|
xfsaild_push(
|
|
|
|
xfs_mount_t *mp,
|
|
|
|
xfs_lsn_t *last_lsn)
|
|
|
|
{
|
|
|
|
long tout = 1000; /* milliseconds */
|
|
|
|
xfs_lsn_t last_pushed_lsn = *last_lsn;
|
|
|
|
xfs_lsn_t target = mp->m_ail.xa_target;
|
|
|
|
xfs_lsn_t lsn;
|
|
|
|
xfs_log_item_t *lip;
|
|
|
|
int gen;
|
|
|
|
int restarts;
|
|
|
|
int flush_log, count, stuck;
|
|
|
|
|
|
|
|
#define XFS_TRANS_PUSH_AIL_RESTARTS 10
|
2005-04-16 18:20:36 -04:00
|
|
|
|
2007-10-11 03:36:05 -04:00
|
|
|
spin_lock(&mp->m_ail_lock);
|
[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-04 20:13:32 -05:00
|
|
|
lip = xfs_trans_first_push_ail(mp, &gen, *last_lsn);
|
|
|
|
if (!lip || XFS_FORCED_SHUTDOWN(mp)) {
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
* AIL is empty or our push has reached the end.
|
2005-04-16 18:20:36 -04:00
|
|
|
*/
|
2007-10-11 03:36:05 -04:00
|
|
|
spin_unlock(&mp->m_ail_lock);
|
[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-04 20:13:32 -05:00
|
|
|
last_pushed_lsn = 0;
|
|
|
|
goto out;
|
2005-04-16 18:20:36 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
XFS_STATS_INC(xs_push_ail);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* While the item we are looking at is below the given threshold
|
[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-04 20:13:32 -05:00
|
|
|
* try to flush it out. We'd like not to stop until we've at least
|
2005-04-16 18:20:36 -04:00
|
|
|
* tried to push on everything in the AIL with an LSN less than
|
[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-04 20:13:32 -05:00
|
|
|
* the given threshold.
|
|
|
|
*
|
|
|
|
* However, we will stop after a certain number of pushes and wait
|
|
|
|
* for a reduced timeout to fire before pushing further. This
|
|
|
|
* prevents use from spinning when we can't do anything or there is
|
|
|
|
* lots of contention on the AIL lists.
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
tout = 10;
|
|
|
|
lsn = lip->li_lsn;
|
|
|
|
flush_log = stuck = count = restarts = 0;
|
|
|
|
while ((XFS_LSN_CMP(lip->li_lsn, target) < 0)) {
|
|
|
|
int lock_result;
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
* If we can lock the item without sleeping, unlock the AIL
|
|
|
|
* lock and flush the item. Then re-grab the AIL lock so we
|
|
|
|
* can look for the next item on the AIL. List changes are
|
|
|
|
* handled by the AIL lookup functions internally
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
* If we can't lock the item, either its holder will flush it
|
|
|
|
* or it is already being flushed or it is being relogged. In
|
|
|
|
* any of these case it is being taken care of and we can just
|
|
|
|
* skip to the next item in the list.
|
2005-04-16 18:20:36 -04:00
|
|
|
*/
|
|
|
|
lock_result = IOP_TRYLOCK(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-04 20:13:32 -05:00
|
|
|
spin_unlock(&mp->m_ail_lock);
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
case XFS_ITEM_SUCCESS:
|
2005-04-16 18:20:36 -04:00
|
|
|
XFS_STATS_INC(xs_push_ail_success);
|
|
|
|
IOP_PUSH(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-04 20:13:32 -05:00
|
|
|
last_pushed_lsn = lsn;
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
case XFS_ITEM_PUSHBUF:
|
2005-04-16 18:20:36 -04:00
|
|
|
XFS_STATS_INC(xs_push_ail_pushbuf);
|
|
|
|
IOP_PUSHBUF(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-04 20:13:32 -05:00
|
|
|
last_pushed_lsn = lsn;
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
case XFS_ITEM_PINNED:
|
2005-04-16 18:20:36 -04:00
|
|
|
XFS_STATS_INC(xs_push_ail_pinned);
|
[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-04 20:13:32 -05:00
|
|
|
stuck++;
|
2005-04-16 18:20:36 -04:00
|
|
|
flush_log = 1;
|
|
|
|
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-04 20:13:32 -05:00
|
|
|
case XFS_ITEM_LOCKED:
|
2005-04-16 18:20:36 -04:00
|
|
|
XFS_STATS_INC(xs_push_ail_locked);
|
[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-04 20:13:32 -05:00
|
|
|
last_pushed_lsn = lsn;
|
|
|
|
stuck++;
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
case XFS_ITEM_FLUSHING:
|
2005-04-16 18:20:36 -04:00
|
|
|
XFS_STATS_INC(xs_push_ail_flushing);
|
[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-04 20:13:32 -05:00
|
|
|
last_pushed_lsn = lsn;
|
|
|
|
stuck++;
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
default:
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
spin_lock(&mp->m_ail_lock);
|
|
|
|
/* should we bother continuing? */
|
|
|
|
if (XFS_FORCED_SHUTDOWN(mp))
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
ASSERT(mp->m_log);
|
|
|
|
|
|
|
|
count++;
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
/*
|
|
|
|
* Are there too many items we can't do anything with?
|
|
|
|
* If we we are skipping too many items because we can't flush
|
|
|
|
* 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;
|
|
|
|
|
|
|
|
lip = xfs_trans_next_ail(mp, lip, &gen, &restarts);
|
|
|
|
if (lip == NULL)
|
|
|
|
break;
|
|
|
|
if (restarts > XFS_TRANS_PUSH_AIL_RESTARTS)
|
|
|
|
break;
|
|
|
|
lsn = lip->li_lsn;
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
spin_unlock(&mp->m_ail_lock);
|
2005-04-16 18:20:36 -04:00
|
|
|
|
|
|
|
if (flush_log) {
|
|
|
|
/*
|
|
|
|
* If something we need to push out was pinned, then
|
|
|
|
* push out the log so it will become unpinned and
|
|
|
|
* move forward in the AIL.
|
|
|
|
*/
|
|
|
|
XFS_STATS_INC(xs_push_ail_flush);
|
|
|
|
xfs_log_force(mp, (xfs_lsn_t)0, XFS_LOG_FORCE);
|
|
|
|
}
|
|
|
|
|
2008-03-05 21:45:10 -05:00
|
|
|
if (!count) {
|
|
|
|
/* We're past our target or empty, so idle */
|
|
|
|
tout = 1000;
|
|
|
|
} else if (XFS_LSN_CMP(lsn, target) >= 0) {
|
|
|
|
/*
|
|
|
|
* We reached the target 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.
|
|
|
|
*/
|
[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-04 20:13:32 -05:00
|
|
|
tout += 20;
|
|
|
|
last_pushed_lsn = 0;
|
|
|
|
} else if ((restarts > XFS_TRANS_PUSH_AIL_RESTARTS) ||
|
2008-03-05 21:45:10 -05:00
|
|
|
((stuck * 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-04 20:13:32 -05: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.
|
|
|
|
*
|
|
|
|
* Backoff a bit more to allow some I/O to complete before
|
|
|
|
* continuing from where we were.
|
|
|
|
*/
|
|
|
|
tout += 10;
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
out:
|
|
|
|
*last_lsn = last_pushed_lsn;
|
|
|
|
return tout;
|
|
|
|
} /* xfsaild_push */
|
2005-04-16 18:20:36 -04:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is to be called when an item is unlocked that may have
|
|
|
|
* been in the AIL. It will wake up the first member of the AIL
|
|
|
|
* wait list if this item's unlocking might allow it to progress.
|
|
|
|
* If the item is in the AIL, then we need to get the AIL lock
|
|
|
|
* while doing our checking so we don't race with someone going
|
|
|
|
* to sleep waiting for this event in xfs_trans_push_ail().
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
xfs_trans_unlocked_item(
|
|
|
|
xfs_mount_t *mp,
|
|
|
|
xfs_log_item_t *lip)
|
|
|
|
{
|
|
|
|
xfs_log_item_t *min_lip;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we're forcibly shutting down, we may have
|
|
|
|
* unlocked log items arbitrarily. The last thing
|
|
|
|
* we want to do is to move the tail of the log
|
|
|
|
* over some potentially valid data.
|
|
|
|
*/
|
|
|
|
if (!(lip->li_flags & XFS_LI_IN_AIL) ||
|
|
|
|
XFS_FORCED_SHUTDOWN(mp)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is the one case where we can call into xfs_ail_min()
|
|
|
|
* without holding the AIL lock because we only care about the
|
|
|
|
* case where we are at the tail of the AIL. If the object isn't
|
|
|
|
* at the tail, it doesn't matter what result we get back. This
|
|
|
|
* is slightly racy because since we were just unlocked, we could
|
|
|
|
* go to sleep between the call to xfs_ail_min and the call to
|
|
|
|
* xfs_log_move_tail, have someone else lock us, commit to us disk,
|
|
|
|
* move us out of the tail of the AIL, and then we wake up. However,
|
|
|
|
* the call to xfs_log_move_tail() doesn't do anything if there's
|
|
|
|
* not enough free space to wake people up so we're safe calling it.
|
|
|
|
*/
|
2008-03-27 02:58:27 -04:00
|
|
|
min_lip = xfs_ail_min(&mp->m_ail);
|
2005-04-16 18:20:36 -04:00
|
|
|
|
|
|
|
if (min_lip == lip)
|
|
|
|
xfs_log_move_tail(mp, 1);
|
|
|
|
} /* xfs_trans_unlocked_item */
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Update the position of the item in the AIL with the new
|
|
|
|
* lsn. If it is not yet in the AIL, add it. Otherwise, move
|
|
|
|
* it to its new position by removing it and re-adding it.
|
|
|
|
*
|
|
|
|
* Wakeup anyone with an lsn less than the item's lsn. If the item
|
|
|
|
* we move in the AIL is the minimum one, update the tail lsn in the
|
|
|
|
* log manager.
|
|
|
|
*
|
|
|
|
* Increment the AIL's generation count to indicate that the tree
|
|
|
|
* has changed.
|
|
|
|
*
|
|
|
|
* This function must be called with the AIL lock held. The lock
|
2007-10-11 03:36:05 -04:00
|
|
|
* is dropped before returning.
|
2005-04-16 18:20:36 -04:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
xfs_trans_update_ail(
|
|
|
|
xfs_mount_t *mp,
|
|
|
|
xfs_log_item_t *lip,
|
2007-10-11 03:36:05 -04:00
|
|
|
xfs_lsn_t lsn) __releases(mp->m_ail_lock)
|
2005-04-16 18:20:36 -04:00
|
|
|
{
|
|
|
|
xfs_log_item_t *dlip=NULL;
|
|
|
|
xfs_log_item_t *mlip; /* ptr to minimum lip */
|
|
|
|
|
2008-03-27 02:58:27 -04:00
|
|
|
mlip = xfs_ail_min(&mp->m_ail);
|
2005-04-16 18:20:36 -04:00
|
|
|
|
|
|
|
if (lip->li_flags & XFS_LI_IN_AIL) {
|
2008-03-27 02:58:27 -04:00
|
|
|
dlip = xfs_ail_delete(&mp->m_ail, lip);
|
2005-04-16 18:20:36 -04:00
|
|
|
ASSERT(dlip == lip);
|
|
|
|
} else {
|
|
|
|
lip->li_flags |= XFS_LI_IN_AIL;
|
|
|
|
}
|
|
|
|
|
|
|
|
lip->li_lsn = lsn;
|
|
|
|
|
2008-03-27 02:58:27 -04:00
|
|
|
xfs_ail_insert(&mp->m_ail, 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-04 20:13:32 -05:00
|
|
|
mp->m_ail.xa_gen++;
|
2005-04-16 18:20:36 -04:00
|
|
|
|
|
|
|
if (mlip == dlip) {
|
2008-03-27 02:58:27 -04:00
|
|
|
mlip = xfs_ail_min(&mp->m_ail);
|
2007-10-11 03:36:05 -04:00
|
|
|
spin_unlock(&mp->m_ail_lock);
|
2005-04-16 18:20:36 -04:00
|
|
|
xfs_log_move_tail(mp, mlip->li_lsn);
|
|
|
|
} else {
|
2007-10-11 03:36:05 -04:00
|
|
|
spin_unlock(&mp->m_ail_lock);
|
2005-04-16 18:20:36 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
} /* xfs_trans_update_ail */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Delete the given item from the AIL. It must already be in
|
|
|
|
* the AIL.
|
|
|
|
*
|
|
|
|
* Wakeup anyone with an lsn less than item's lsn. If the item
|
|
|
|
* we delete in the AIL is the minimum one, update the tail lsn in the
|
|
|
|
* log manager.
|
|
|
|
*
|
|
|
|
* Clear the IN_AIL flag from the item, reset its lsn to 0, and
|
|
|
|
* bump the AIL's generation count to indicate that the tree
|
|
|
|
* has changed.
|
|
|
|
*
|
|
|
|
* This function must be called with the AIL lock held. The lock
|
2007-10-11 03:36:05 -04:00
|
|
|
* is dropped before returning.
|
2005-04-16 18:20:36 -04:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
xfs_trans_delete_ail(
|
|
|
|
xfs_mount_t *mp,
|
2007-10-11 03:36:05 -04:00
|
|
|
xfs_log_item_t *lip) __releases(mp->m_ail_lock)
|
2005-04-16 18:20:36 -04:00
|
|
|
{
|
|
|
|
xfs_log_item_t *dlip;
|
|
|
|
xfs_log_item_t *mlip;
|
|
|
|
|
|
|
|
if (lip->li_flags & XFS_LI_IN_AIL) {
|
2008-03-27 02:58:27 -04:00
|
|
|
mlip = xfs_ail_min(&mp->m_ail);
|
|
|
|
dlip = xfs_ail_delete(&mp->m_ail, lip);
|
2005-04-16 18:20:36 -04:00
|
|
|
ASSERT(dlip == lip);
|
|
|
|
|
|
|
|
|
|
|
|
lip->li_flags &= ~XFS_LI_IN_AIL;
|
|
|
|
lip->li_lsn = 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-04 20:13:32 -05:00
|
|
|
mp->m_ail.xa_gen++;
|
2005-04-16 18:20:36 -04:00
|
|
|
|
|
|
|
if (mlip == dlip) {
|
2008-03-27 02:58:27 -04:00
|
|
|
mlip = xfs_ail_min(&mp->m_ail);
|
2007-10-11 03:36:05 -04:00
|
|
|
spin_unlock(&mp->m_ail_lock);
|
2005-04-16 18:20:36 -04:00
|
|
|
xfs_log_move_tail(mp, (mlip ? mlip->li_lsn : 0));
|
|
|
|
} else {
|
2007-10-11 03:36:05 -04:00
|
|
|
spin_unlock(&mp->m_ail_lock);
|
2005-04-16 18:20:36 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
/*
|
|
|
|
* If the file system is not being shutdown, we are in
|
|
|
|
* serious trouble if we get to this stage.
|
|
|
|
*/
|
|
|
|
if (XFS_FORCED_SHUTDOWN(mp))
|
2007-10-11 03:36:05 -04:00
|
|
|
spin_unlock(&mp->m_ail_lock);
|
2005-04-16 18:20:36 -04:00
|
|
|
else {
|
|
|
|
xfs_cmn_err(XFS_PTAG_AILDELETE, CE_ALERT, mp,
|
2006-06-09 00:58:38 -04:00
|
|
|
"%s: attempting to delete a log item that is not in the AIL",
|
2008-04-09 22:19:21 -04:00
|
|
|
__func__);
|
2007-10-11 03:36:05 -04:00
|
|
|
spin_unlock(&mp->m_ail_lock);
|
2006-06-09 00:58:38 -04:00
|
|
|
xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE);
|
2005-04-16 18:20:36 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return the item in the AIL with the smallest lsn.
|
|
|
|
* Return the current tree generation number for use
|
|
|
|
* in calls to xfs_trans_next_ail().
|
|
|
|
*/
|
|
|
|
xfs_log_item_t *
|
|
|
|
xfs_trans_first_ail(
|
|
|
|
xfs_mount_t *mp,
|
|
|
|
int *gen)
|
|
|
|
{
|
|
|
|
xfs_log_item_t *lip;
|
|
|
|
|
2008-03-27 02:58:27 -04:00
|
|
|
lip = xfs_ail_min(&mp->m_ail);
|
[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-04 20:13:32 -05:00
|
|
|
*gen = (int)mp->m_ail.xa_gen;
|
2005-04-16 18:20:36 -04: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-04 20:13:32 -05:00
|
|
|
return lip;
|
2005-04-16 18:20:36 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the generation count of the tree has not changed since the
|
|
|
|
* caller last took something from the AIL, then return the elmt
|
|
|
|
* in the tree which follows the one given. If the count has changed,
|
|
|
|
* then return the minimum elmt of the AIL and bump the restarts counter
|
|
|
|
* if one is given.
|
|
|
|
*/
|
|
|
|
xfs_log_item_t *
|
|
|
|
xfs_trans_next_ail(
|
|
|
|
xfs_mount_t *mp,
|
|
|
|
xfs_log_item_t *lip,
|
|
|
|
int *gen,
|
|
|
|
int *restarts)
|
|
|
|
{
|
|
|
|
xfs_log_item_t *nlip;
|
|
|
|
|
|
|
|
ASSERT(mp && lip && gen);
|
[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-04 20:13:32 -05:00
|
|
|
if (mp->m_ail.xa_gen == *gen) {
|
2008-03-27 02:58:27 -04:00
|
|
|
nlip = xfs_ail_next(&mp->m_ail, lip);
|
2005-04-16 18:20:36 -04:00
|
|
|
} else {
|
2008-03-27 02:58:27 -04:00
|
|
|
nlip = xfs_ail_min(&mp->m_ail);
|
[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-04 20:13:32 -05:00
|
|
|
*gen = (int)mp->m_ail.xa_gen;
|
2005-04-16 18:20:36 -04:00
|
|
|
if (restarts != NULL) {
|
|
|
|
XFS_STATS_INC(xs_push_ail_restarts);
|
|
|
|
(*restarts)++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return (nlip);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The active item list (AIL) is a doubly linked list of log
|
|
|
|
* items sorted by ascending lsn. The base of the list is
|
|
|
|
* a forw/back pointer pair embedded in the xfs mount structure.
|
|
|
|
* The base is initialized with both pointers pointing to the
|
|
|
|
* base. This case always needs to be distinguished, because
|
|
|
|
* the base has no lsn to look at. We almost always insert
|
|
|
|
* at the end of the list, so on inserts we search from the
|
|
|
|
* end of the list to find where the new item belongs.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize the doubly linked list to point only to itself.
|
|
|
|
*/
|
[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-04 20:13:32 -05:00
|
|
|
int
|
2005-04-16 18:20:36 -04:00
|
|
|
xfs_trans_ail_init(
|
|
|
|
xfs_mount_t *mp)
|
|
|
|
{
|
2008-03-27 02:58:27 -04:00
|
|
|
INIT_LIST_HEAD(&mp->m_ail.xa_ail);
|
[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-04 20:13:32 -05:00
|
|
|
return xfsaild_start(mp);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
xfs_trans_ail_destroy(
|
|
|
|
xfs_mount_t *mp)
|
|
|
|
{
|
|
|
|
xfsaild_stop(mp);
|
2005-04-16 18:20:36 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Insert the given log item into the AIL.
|
|
|
|
* We almost always insert at the end of the list, so on inserts
|
|
|
|
* we search from the end of the list to find where the
|
|
|
|
* new item belongs.
|
|
|
|
*/
|
|
|
|
STATIC void
|
|
|
|
xfs_ail_insert(
|
2008-03-27 02:58:27 -04:00
|
|
|
xfs_ail_t *ailp,
|
2005-04-16 18:20:36 -04:00
|
|
|
xfs_log_item_t *lip)
|
|
|
|
/* ARGSUSED */
|
|
|
|
{
|
|
|
|
xfs_log_item_t *next_lip;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the list is empty, just insert the item.
|
|
|
|
*/
|
2008-03-27 02:58:27 -04:00
|
|
|
if (list_empty(&ailp->xa_ail)) {
|
|
|
|
list_add(&lip->li_ail, &ailp->xa_ail);
|
2005-04-16 18:20:36 -04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2008-03-27 02:58:27 -04:00
|
|
|
list_for_each_entry_reverse(next_lip, &ailp->xa_ail, li_ail) {
|
|
|
|
if (XFS_LSN_CMP(next_lip->li_lsn, lip->li_lsn) <= 0)
|
|
|
|
break;
|
2005-04-16 18:20:36 -04:00
|
|
|
}
|
2008-03-27 02:58:27 -04:00
|
|
|
|
|
|
|
ASSERT((&next_lip->li_ail == &ailp->xa_ail) ||
|
2005-04-16 18:20:36 -04:00
|
|
|
(XFS_LSN_CMP(next_lip->li_lsn, lip->li_lsn) <= 0));
|
|
|
|
|
2008-03-27 02:58:27 -04:00
|
|
|
list_add(&lip->li_ail, &next_lip->li_ail);
|
|
|
|
|
|
|
|
xfs_ail_check(ailp, lip);
|
2005-04-16 18:20:36 -04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Delete the given item from the AIL. Return a pointer to the item.
|
|
|
|
*/
|
|
|
|
/*ARGSUSED*/
|
|
|
|
STATIC xfs_log_item_t *
|
|
|
|
xfs_ail_delete(
|
2008-03-27 02:58:27 -04:00
|
|
|
xfs_ail_t *ailp,
|
2005-04-16 18:20:36 -04:00
|
|
|
xfs_log_item_t *lip)
|
|
|
|
/* ARGSUSED */
|
|
|
|
{
|
2008-03-27 02:58:27 -04:00
|
|
|
xfs_ail_check(ailp, lip);
|
|
|
|
|
|
|
|
list_del(&lip->li_ail);
|
2005-04-16 18:20:36 -04:00
|
|
|
|
|
|
|
return lip;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return a pointer to the first item in the AIL.
|
|
|
|
* If the AIL is empty, then return NULL.
|
|
|
|
*/
|
|
|
|
STATIC xfs_log_item_t *
|
|
|
|
xfs_ail_min(
|
2008-03-27 02:58:27 -04:00
|
|
|
xfs_ail_t *ailp)
|
2005-04-16 18:20:36 -04:00
|
|
|
/* ARGSUSED */
|
|
|
|
{
|
2008-03-27 02:58:27 -04:00
|
|
|
if (list_empty(&ailp->xa_ail))
|
2005-04-16 18:20:36 -04:00
|
|
|
return NULL;
|
2008-03-27 02:58:27 -04:00
|
|
|
|
|
|
|
return list_first_entry(&ailp->xa_ail, xfs_log_item_t, li_ail);
|
2005-04-16 18:20:36 -04: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.
|
|
|
|
*/
|
|
|
|
STATIC xfs_log_item_t *
|
|
|
|
xfs_ail_next(
|
2008-03-27 02:58:27 -04:00
|
|
|
xfs_ail_t *ailp,
|
2005-04-16 18:20:36 -04:00
|
|
|
xfs_log_item_t *lip)
|
|
|
|
/* ARGSUSED */
|
|
|
|
{
|
2008-03-27 02:58:27 -04:00
|
|
|
if (lip->li_ail.next == &ailp->xa_ail)
|
2005-04-16 18:20:36 -04:00
|
|
|
return NULL;
|
|
|
|
|
2008-03-27 02:58:27 -04:00
|
|
|
return list_first_entry(&lip->li_ail, xfs_log_item_t, li_ail);
|
2005-04-16 18:20:36 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef DEBUG
|
|
|
|
/*
|
|
|
|
* Check that the list is sorted as it should be.
|
|
|
|
*/
|
|
|
|
STATIC void
|
|
|
|
xfs_ail_check(
|
2008-03-27 02:58:27 -04:00
|
|
|
xfs_ail_t *ailp,
|
2008-02-04 20:13:38 -05:00
|
|
|
xfs_log_item_t *lip)
|
2005-04-16 18:20:36 -04:00
|
|
|
{
|
|
|
|
xfs_log_item_t *prev_lip;
|
|
|
|
|
2008-03-27 02:58:27 -04:00
|
|
|
if (list_empty(&ailp->xa_ail))
|
2005-04-16 18:20:36 -04:00
|
|
|
return;
|
|
|
|
|
2008-02-04 20:13:38 -05:00
|
|
|
/*
|
|
|
|
* Check the next and previous entries are valid.
|
|
|
|
*/
|
|
|
|
ASSERT((lip->li_flags & XFS_LI_IN_AIL) != 0);
|
2008-03-27 02:58:27 -04:00
|
|
|
prev_lip = list_entry(lip->li_ail.prev, xfs_log_item_t, li_ail);
|
|
|
|
if (&prev_lip->li_ail != &ailp->xa_ail)
|
2008-02-04 20:13:38 -05:00
|
|
|
ASSERT(XFS_LSN_CMP(prev_lip->li_lsn, lip->li_lsn) <= 0);
|
2008-03-27 02:58:27 -04:00
|
|
|
|
|
|
|
prev_lip = list_entry(lip->li_ail.next, xfs_log_item_t, li_ail);
|
|
|
|
if (&prev_lip->li_ail != &ailp->xa_ail)
|
2008-02-04 20:13:38 -05:00
|
|
|
ASSERT(XFS_LSN_CMP(prev_lip->li_lsn, lip->li_lsn) >= 0);
|
|
|
|
|
|
|
|
|
|
|
|
#ifdef XFS_TRANS_DEBUG
|
2005-04-16 18:20:36 -04:00
|
|
|
/*
|
2008-03-27 02:58:27 -04:00
|
|
|
* Walk the list checking lsn ordering, and that every entry has the
|
|
|
|
* XFS_LI_IN_AIL flag set. This is really expensive, so only do it
|
|
|
|
* when specifically debugging the transaction subsystem.
|
2005-04-16 18:20:36 -04:00
|
|
|
*/
|
2008-03-27 02:58:27 -04:00
|
|
|
prev_lip = list_entry(&ailp->xa_ail, xfs_log_item_t, li_ail);
|
|
|
|
list_for_each_entry(lip, &ailp->xa_ail, li_ail) {
|
|
|
|
if (&prev_lip->li_ail != &ailp->xa_ail)
|
2005-04-16 18:20:36 -04:00
|
|
|
ASSERT(XFS_LSN_CMP(prev_lip->li_lsn, lip->li_lsn) <= 0);
|
|
|
|
ASSERT((lip->li_flags & XFS_LI_IN_AIL) != 0);
|
|
|
|
prev_lip = lip;
|
|
|
|
}
|
2008-02-04 20:13:38 -05:00
|
|
|
#endif /* XFS_TRANS_DEBUG */
|
2005-04-16 18:20:36 -04:00
|
|
|
}
|
|
|
|
#endif /* DEBUG */
|