2018-06-06 05:42:14 +03:00
// SPDX-License-Identifier: GPL-2.0
2005-04-17 02:20:36 +04:00
/*
2005-11-02 06:58:39 +03:00
* Copyright ( c ) 2000 - 2002 , 2005 Silicon Graphics , Inc .
2008-10-30 09:39:23 +03:00
* Copyright ( c ) 2008 Dave Chinner
2005-11-02 06:58:39 +03:00
* All Rights Reserved .
2005-04-17 02:20:36 +04:00
*/
# include "xfs.h"
2005-11-02 06:38:42 +03:00
# include "xfs_fs.h"
2019-06-29 05:25:35 +03:00
# include "xfs_shared.h"
2014-11-28 06:25:04 +03:00
# include "xfs_format.h"
2013-10-23 03:50:10 +04:00
# include "xfs_log_format.h"
# include "xfs_trans_resv.h"
2005-04-17 02:20:36 +04:00
# include "xfs_mount.h"
2013-10-23 03:50:10 +04:00
# include "xfs_trans.h"
2005-04-17 02:20:36 +04:00
# include "xfs_trans_priv.h"
2011-10-11 19:14:11 +04:00
# include "xfs_trace.h"
2017-10-31 22:04:49 +03:00
# include "xfs_errortag.h"
2005-04-17 02:20:36 +04:00
# include "xfs_error.h"
2013-10-23 03:50:10 +04:00
# include "xfs_log.h"
2005-04-17 02:20:36 +04:00
# ifdef DEBUG
2011-04-08 06:45:07 +04:00
/*
* Check that the list is sorted as it should be .
2018-05-09 17:49:09 +03:00
*
* Called with the ail lock held , but we don ' t want to assert fail with it
* held otherwise we ' ll lock everything up and won ' t be able to debug the
* cause . Hence we sample and check the state under the AIL lock and return if
* everything is fine , otherwise we drop the lock and run the ASSERT checks .
* Asserts may not be fatal , so pick the lock back up and continue onwards .
2011-04-08 06:45:07 +04:00
*/
STATIC void
xfs_ail_check (
2018-05-09 17:49:09 +03:00
struct xfs_ail * ailp ,
struct xfs_log_item * lip )
2020-02-26 20:37:15 +03:00
__must_hold ( & ailp - > ail_lock )
2011-04-08 06:45:07 +04:00
{
2018-05-09 17:49:09 +03:00
struct xfs_log_item * prev_lip ;
struct xfs_log_item * next_lip ;
xfs_lsn_t prev_lsn = NULLCOMMITLSN ;
xfs_lsn_t next_lsn = NULLCOMMITLSN ;
xfs_lsn_t lsn ;
bool in_ail ;
2011-04-08 06:45:07 +04:00
2018-03-08 01:59:39 +03:00
if ( list_empty ( & ailp - > ail_head ) )
2011-04-08 06:45:07 +04:00
return ;
/*
2018-05-09 17:49:09 +03:00
* Sample then check the next and previous entries are valid .
2011-04-08 06:45:07 +04:00
*/
2018-05-09 17:49:09 +03:00
in_ail = test_bit ( XFS_LI_IN_AIL , & lip - > li_flags ) ;
prev_lip = list_entry ( lip - > li_ail . prev , struct xfs_log_item , li_ail ) ;
2018-03-08 01:59:39 +03:00
if ( & prev_lip - > li_ail ! = & ailp - > ail_head )
2018-05-09 17:49:09 +03:00
prev_lsn = prev_lip - > li_lsn ;
next_lip = list_entry ( lip - > li_ail . next , struct xfs_log_item , li_ail ) ;
if ( & next_lip - > li_ail ! = & ailp - > ail_head )
next_lsn = next_lip - > li_lsn ;
lsn = lip - > li_lsn ;
2011-04-08 06:45:07 +04:00
2018-05-09 17:49:09 +03:00
if ( in_ail & &
( prev_lsn = = NULLCOMMITLSN | | XFS_LSN_CMP ( prev_lsn , lsn ) < = 0 ) & &
( next_lsn = = NULLCOMMITLSN | | XFS_LSN_CMP ( next_lsn , lsn ) > = 0 ) )
return ;
2011-04-08 06:45:07 +04:00
2018-05-09 17:49:09 +03:00
spin_unlock ( & ailp - > ail_lock ) ;
ASSERT ( in_ail ) ;
ASSERT ( prev_lsn = = NULLCOMMITLSN | | XFS_LSN_CMP ( prev_lsn , lsn ) < = 0 ) ;
ASSERT ( next_lsn = = NULLCOMMITLSN | | XFS_LSN_CMP ( next_lsn , lsn ) > = 0 ) ;
spin_lock ( & ailp - > ail_lock ) ;
2011-04-08 06:45:07 +04:00
}
# else /* !DEBUG */
2008-02-05 04:13:38 +03:00
# define xfs_ail_check(a,l)
2005-04-17 02:20:36 +04:00
# endif /* DEBUG */
2011-04-08 06:45:07 +04:00
/*
2011-04-08 06:45:07 +04:00
* Return a pointer to the last item in the AIL . If the AIL is empty , then
* return NULL .
*/
2019-06-29 05:27:33 +03:00
static struct xfs_log_item *
2011-04-08 06:45:07 +04:00
xfs_ail_max (
struct xfs_ail * ailp )
{
2018-03-08 01:59:39 +03:00
if ( list_empty ( & ailp - > ail_head ) )
2011-04-08 06:45:07 +04:00
return NULL ;
2019-06-29 05:27:33 +03:00
return list_entry ( ailp - > ail_head . prev , struct xfs_log_item , li_ail ) ;
2011-04-08 06:45:07 +04:00
}
2011-04-08 06:45:07 +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 .
*/
2019-06-29 05:27:33 +03:00
static struct xfs_log_item *
2011-04-08 06:45:07 +04:00
xfs_ail_next (
2019-06-29 05:27:33 +03:00
struct xfs_ail * ailp ,
struct xfs_log_item * lip )
2011-04-08 06:45:07 +04:00
{
2018-03-08 01:59:39 +03:00
if ( lip - > li_ail . next = = & ailp - > ail_head )
2011-04-08 06:45:07 +04:00
return NULL ;
2019-06-29 05:27:33 +03:00
return list_first_entry ( & lip - > li_ail , struct xfs_log_item , li_ail ) ;
2011-04-08 06:45:07 +04:00
}
2005-04-17 02:20:36 +04:00
/*
2011-04-08 06:45:07 +04:00
* This is called by the log manager code to determine the LSN of the tail of
* the log . This is exactly the LSN of the first item in the AIL . If the AIL
* is empty , then this function returns 0.
2005-04-17 02:20:36 +04:00
*
2011-04-08 06:45:07 +04:00
* We need the AIL lock in order to get a coherent read of the lsn of the last
* item in the AIL .
2005-04-17 02:20:36 +04:00
*/
2020-03-25 06:10:29 +03:00
static xfs_lsn_t
__xfs_ail_min_lsn (
struct xfs_ail * ailp )
{
struct xfs_log_item * lip = xfs_ail_min ( ailp ) ;
if ( lip )
return lip - > li_lsn ;
return 0 ;
}
2005-04-17 02:20:36 +04:00
xfs_lsn_t
2011-04-08 06:45:07 +04:00
xfs_ail_min_lsn (
2019-06-29 05:27:33 +03:00
struct xfs_ail * ailp )
2005-04-17 02:20:36 +04:00
{
2020-03-25 06:10:29 +03:00
xfs_lsn_t lsn ;
2005-04-17 02:20:36 +04:00
2018-03-08 01:59:39 +03:00
spin_lock ( & ailp - > ail_lock ) ;
2020-03-25 06:10:29 +03:00
lsn = __xfs_ail_min_lsn ( ailp ) ;
2018-03-08 01:59:39 +03:00
spin_unlock ( & ailp - > ail_lock ) ;
2005-04-17 02:20:36 +04:00
return lsn ;
}
2011-04-08 06:45:07 +04:00
/*
* Return the maximum lsn held in the AIL , or zero if the AIL is empty .
*/
static xfs_lsn_t
xfs_ail_max_lsn (
2019-06-29 05:27:33 +03:00
struct xfs_ail * ailp )
2011-04-08 06:45:07 +04:00
{
2019-06-29 05:27:33 +03:00
xfs_lsn_t lsn = 0 ;
struct xfs_log_item * lip ;
2011-04-08 06:45:07 +04:00
2018-03-08 01:59:39 +03:00
spin_lock ( & ailp - > ail_lock ) ;
2011-04-08 06:45:07 +04:00
lip = xfs_ail_max ( ailp ) ;
if ( lip )
lsn = lip - > li_lsn ;
2018-03-08 01:59:39 +03:00
spin_unlock ( & ailp - > ail_lock ) ;
2011-04-08 06:45:07 +04:00
return lsn ;
}
2008-10-30 09:38:39 +03:00
/*
2011-07-18 07:40:18 +04:00
* The cursor keeps track of where our current traversal is up to by tracking
* the next item in the list for us . However , for this to be safe , removing an
* object from the AIL needs to invalidate any cursor that points to it . hence
* the traversal cursor needs to be linked to the struct xfs_ail so that
* deletion can search all the active cursors for invalidation .
2008-10-30 09:38:39 +03:00
*/
2008-10-30 09:39:00 +03:00
STATIC void
2008-10-30 09:38:39 +03:00
xfs_trans_ail_cursor_init (
struct xfs_ail * ailp ,
struct xfs_ail_cursor * cur )
{
cur - > item = NULL ;
2018-03-08 01:59:39 +03:00
list_add_tail ( & cur - > list , & ailp - > ail_cursors ) ;
2008-10-30 09:38:39 +03:00
}
/*
2011-07-18 07:40:18 +04:00
* Get the next item in the traversal and advance the cursor . If the cursor
* was invalidated ( indicated by a lip of 1 ) , restart the traversal .
2008-10-30 09:38:39 +03:00
*/
2008-10-30 09:39:00 +03:00
struct xfs_log_item *
2008-10-30 09:38:39 +03:00
xfs_trans_ail_cursor_next (
struct xfs_ail * ailp ,
struct xfs_ail_cursor * cur )
{
struct xfs_log_item * lip = cur - > item ;
2015-06-22 02:43:32 +03:00
if ( ( uintptr_t ) lip & 1 )
2008-10-30 09:38:39 +03:00
lip = xfs_ail_min ( ailp ) ;
2011-07-18 07:40:17 +04:00
if ( lip )
cur - > item = xfs_ail_next ( ailp , lip ) ;
2008-10-30 09:38:39 +03:00
return lip ;
}
/*
2011-07-18 07:40:18 +04:00
* When the traversal is complete , we need to remove the cursor from the list
* of traversing cursors .
2008-10-30 09:38:39 +03:00
*/
void
xfs_trans_ail_cursor_done (
2011-07-18 07:40:18 +04:00
struct xfs_ail_cursor * cur )
2008-10-30 09:38:39 +03:00
{
2011-07-18 07:40:18 +04:00
cur - > item = NULL ;
list_del_init ( & cur - > list ) ;
2008-10-30 09:38:39 +03:00
}
2008-10-30 09:39:00 +03:00
/*
2011-07-18 07:40:18 +04:00
* Invalidate any cursor that is pointing to this item . This is called when an
* item is removed from the AIL . Any cursor pointing to this object is now
* invalid and the traversal needs to be terminated so it doesn ' t reference a
* freed object . We set the low bit of the cursor item pointer so we can
* distinguish between an invalidation and the end of the list when getting the
* next item from the cursor .
2008-10-30 09:39:00 +03:00
*/
STATIC void
xfs_trans_ail_cursor_clear (
struct xfs_ail * ailp ,
struct xfs_log_item * lip )
{
struct xfs_ail_cursor * cur ;
2018-03-08 01:59:39 +03:00
list_for_each_entry ( cur , & ailp - > ail_cursors , list ) {
2008-10-30 09:39:00 +03:00
if ( cur - > item = = lip )
cur - > item = ( struct xfs_log_item * )
2015-06-22 02:43:32 +03:00
( ( uintptr_t ) cur - > item | 1 ) ;
2008-10-30 09:39:00 +03:00
}
}
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 04:13:32 +03:00
/*
2011-07-18 07:40:17 +04:00
* Find the first item in the AIL with the given @ lsn by searching in ascending
* LSN order and initialise the cursor to point to the next item for a
* ascending traversal . Pass a @ lsn of zero to initialise the cursor to the
* first item in the AIL . Returns NULL if the list is empty .
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 04:13:32 +03:00
*/
2019-06-29 05:27:33 +03:00
struct xfs_log_item *
2008-10-30 09:39:00 +03:00
xfs_trans_ail_cursor_first (
2008-10-30 09:38:39 +03:00
struct xfs_ail * ailp ,
struct xfs_ail_cursor * cur ,
xfs_lsn_t lsn )
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 04:13:32 +03:00
{
2019-06-29 05:27:33 +03:00
struct xfs_log_item * lip ;
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 04:13:32 +03:00
2008-10-30 09:39:00 +03:00
xfs_trans_ail_cursor_init ( ailp , cur ) ;
2011-07-18 07:40:17 +04:00
if ( lsn = = 0 ) {
lip = xfs_ail_min ( ailp ) ;
2008-10-30 09:39:00 +03:00
goto out ;
2011-07-18 07:40:17 +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-05 04:13:32 +03:00
2018-03-08 01:59:39 +03:00
list_for_each_entry ( lip , & ailp - > ail_head , li_ail ) {
2008-10-30 09:39:00 +03:00
if ( XFS_LSN_CMP ( lip - > li_lsn , lsn ) > = 0 )
2008-10-30 10:26:51 +03:00
goto out ;
2008-03-27 09:58:27 +03:00
}
2011-07-18 07:40:17 +04:00
return NULL ;
2008-10-30 09:39:00 +03:00
out :
2011-07-18 07:40:17 +04:00
if ( lip )
cur - > item = xfs_ail_next ( ailp , lip ) ;
2008-10-30 09:39:00 +03:00
return lip ;
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 04:13:32 +03:00
}
2011-07-18 07:40:16 +04:00
static struct xfs_log_item *
__xfs_trans_ail_cursor_last (
struct xfs_ail * ailp ,
xfs_lsn_t lsn )
{
2019-06-29 05:27:33 +03:00
struct xfs_log_item * lip ;
2011-07-18 07:40:16 +04:00
2018-03-08 01:59:39 +03:00
list_for_each_entry_reverse ( lip , & ailp - > ail_head , li_ail ) {
2011-07-18 07:40:16 +04:00
if ( XFS_LSN_CMP ( lip - > li_lsn , lsn ) < = 0 )
return lip ;
}
return NULL ;
}
/*
2011-07-18 07:40:17 +04:00
* Find the last item in the AIL with the given @ lsn by searching in descending
* LSN order and initialise the cursor to point to that item . If there is no
* item with the value of @ lsn , then it sets the cursor to the last item with an
* LSN lower than @ lsn . Returns NULL if the list is empty .
2011-07-18 07:40:16 +04:00
*/
struct xfs_log_item *
xfs_trans_ail_cursor_last (
struct xfs_ail * ailp ,
struct xfs_ail_cursor * cur ,
xfs_lsn_t lsn )
{
xfs_trans_ail_cursor_init ( ailp , cur ) ;
cur - > item = __xfs_trans_ail_cursor_last ( ailp , lsn ) ;
return cur - > item ;
}
/*
2011-07-18 07:40:17 +04:00
* Splice the log item list into the AIL at the given LSN . We splice to the
2011-07-18 07:40:16 +04:00
* tail of the given LSN to maintain insert order for push traversals . The
* cursor is optional , allowing repeated updates to the same LSN to avoid
2011-07-22 20:04:41 +04:00
* repeated traversals . This should not be called with an empty list .
2011-04-08 06:45:07 +04:00
*/
static void
xfs_ail_splice (
2011-07-18 07:40:16 +04:00
struct xfs_ail * ailp ,
struct xfs_ail_cursor * cur ,
struct list_head * list ,
xfs_lsn_t lsn )
2011-04-08 06:45:07 +04:00
{
2011-07-22 20:04:41 +04:00
struct xfs_log_item * lip ;
ASSERT ( ! list_empty ( list ) ) ;
2011-04-08 06:45:07 +04:00
2011-07-18 07:40:16 +04:00
/*
2011-07-22 20:04:41 +04:00
* Use the cursor to determine the insertion point if one is
* provided . If not , or if the one we got is not valid ,
* find the place in the AIL where the items belong .
2011-07-18 07:40:16 +04:00
*/
2011-07-22 20:04:41 +04:00
lip = cur ? cur - > item : NULL ;
2015-06-22 02:43:32 +03:00
if ( ! lip | | ( uintptr_t ) lip & 1 )
2011-07-18 07:40:16 +04:00
lip = __xfs_trans_ail_cursor_last ( ailp , lsn ) ;
2011-07-22 20:04:41 +04:00
/*
* If a cursor is provided , we know we ' re processing the AIL
* in lsn order , and future items to be spliced in will
* follow the last one being inserted now . Update the
* cursor to point to that last item , now while we have a
* reliable pointer to it .
*/
if ( cur )
cur - > item = list_entry ( list - > prev , struct xfs_log_item , li_ail ) ;
2011-04-08 06:45:07 +04:00
2011-07-18 07:40:16 +04:00
/*
2011-07-22 20:04:41 +04:00
* Finally perform the splice . Unless the AIL was empty ,
* lip points to the item in the AIL _after_ which the new
* items should go . If lip is null the AIL was empty , so
* the new items go at the head of the AIL .
2011-07-18 07:40:16 +04:00
*/
2011-07-22 20:04:41 +04:00
if ( lip )
list_splice ( list , & lip - > li_ail ) ;
else
2018-03-08 01:59:39 +03:00
list_splice ( list , & ailp - > ail_head ) ;
2011-04-08 06:45:07 +04:00
}
/*
* Delete the given item from the AIL . Return a pointer to the item .
*/
static void
xfs_ail_delete (
2019-06-29 05:27:33 +03:00
struct xfs_ail * ailp ,
struct xfs_log_item * lip )
2011-04-08 06:45:07 +04:00
{
xfs_ail_check ( ailp , lip ) ;
list_del ( & lip - > li_ail ) ;
xfs_trans_ail_cursor_clear ( ailp , lip ) ;
}
2020-05-06 23:25:19 +03:00
/*
* Requeue a failed buffer for writeback .
*
* We clear the log item failed state here as well , but we have to be careful
* about reference counts because the only active reference counts on the buffer
* may be the failed log items . Hence if we clear the log item failed state
* before queuing the buffer for IO we can release all active references to
* the buffer and free it , leading to use after free problems in
* xfs_buf_delwri_queue . It makes no difference to the buffer or log items which
* order we process them in - the buffer is locked , and we own the buffer list
* so nothing on them is going to change while we are performing this action .
*
* Hence we can safely queue the buffer for IO before we clear the failed log
* item state , therefore always having an active reference to the buffer and
* avoiding the transient zero - reference state that leads to use - after - free .
*/
static inline int
xfsaild_resubmit_item (
struct xfs_log_item * lip ,
struct list_head * buffer_list )
{
struct xfs_buf * bp = lip - > li_buf ;
if ( ! xfs_buf_trylock ( bp ) )
return XFS_ITEM_LOCKED ;
if ( ! xfs_buf_delwri_queue ( bp , buffer_list ) ) {
xfs_buf_unlock ( bp ) ;
return XFS_ITEM_FLUSHING ;
}
/* protected by ail_lock */
xfs: pin inode backing buffer to the inode log item
When we dirty an inode, we are going to have to write it disk at
some point in the near future. This requires the inode cluster
backing buffer to be present in memory. Unfortunately, under severe
memory pressure we can reclaim the inode backing buffer while the
inode is dirty in memory, resulting in stalling the AIL pushing
because it has to do a read-modify-write cycle on the cluster
buffer.
When we have no memory available, the read of the cluster buffer
blocks the AIL pushing process, and this causes all sorts of issues
for memory reclaim as it requires inode writeback to make forwards
progress. Allocating a cluster buffer causes more memory pressure,
and results in more cluster buffers to be reclaimed, resulting in
more RMW cycles to be done in the AIL context and everything then
backs up on AIL progress. Only the synchronous inode cluster
writeback in the the inode reclaim code provides some level of
forwards progress guarantees that prevent OOM-killer rampages in
this situation.
Fix this by pinning the inode backing buffer to the inode log item
when the inode is first dirtied (i.e. in xfs_trans_log_inode()).
This may mean the first modification of an inode that has been held
in cache for a long time may block on a cluster buffer read, but
we can do that in transaction context and block safely until the
buffer has been allocated and read.
Once we have the cluster buffer, the inode log item takes a
reference to it, pinning it in memory, and attaches it to the log
item for future reference. This means we can always grab the cluster
buffer from the inode log item when we need it.
When the inode is finally cleaned and removed from the AIL, we can
drop the reference the inode log item holds on the cluster buffer.
Once all inodes on the cluster buffer are clean, the cluster buffer
will be unpinned and it will be available for memory reclaim to
reclaim again.
This avoids the issues with needing to do RMW cycles in the AIL
pushing context, and hence allows complete non-blocking inode
flushing to be performed by the AIL pushing context.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2020-06-30 00:49:15 +03:00
list_for_each_entry ( lip , & bp - > b_li_list , li_bio_list ) {
if ( bp - > b_flags & _XBF_INODES )
clear_bit ( XFS_LI_FAILED , & lip - > li_flags ) ;
else
xfs_clear_li_failed ( lip ) ;
}
2020-05-06 23:25:19 +03:00
xfs_buf_unlock ( bp ) ;
return XFS_ITEM_SUCCESS ;
}
2017-08-09 04:21:52 +03:00
static inline uint
xfsaild_push_item (
struct xfs_ail * ailp ,
struct xfs_log_item * lip )
{
/*
* If log item pinning is enabled , skip the push and track the item as
* pinned . This can help induce head - behind - tail conditions .
*/
2018-03-08 01:59:39 +03:00
if ( XFS_TEST_ERROR ( false , ailp - > ail_mount , XFS_ERRTAG_LOG_ITEM_PIN ) )
2017-08-09 04:21:52 +03:00
return XFS_ITEM_PINNED ;
2019-06-29 05:27:30 +03:00
/*
* Consider the item pinned if a push callback is not defined so the
* caller will force the log . This should only happen for intent items
* as they are unpinned once the associated done item is committed to
* the on - disk log .
*/
if ( ! lip - > li_ops - > iop_push )
return XFS_ITEM_PINNED ;
2020-05-06 23:25:19 +03:00
if ( test_bit ( XFS_LI_FAILED , & lip - > li_flags ) )
return xfsaild_resubmit_item ( lip , & ailp - > ail_buf_list ) ;
2018-03-08 01:59:39 +03:00
return lip - > li_ops - > iop_push ( lip , & ailp - > ail_buf_list ) ;
2017-08-09 04:21:52 +03:00
}
2011-10-11 19:14:10 +04:00
static long
xfsaild_push (
struct xfs_ail * ailp )
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 04:13:32 +03:00
{
2018-03-08 01:59:39 +03:00
xfs_mount_t * mp = ailp - > ail_mount ;
2011-07-18 07:40:18 +04:00
struct xfs_ail_cursor cur ;
2019-06-29 05:27:33 +03:00
struct xfs_log_item * lip ;
2011-05-06 06:54:05 +04:00
xfs_lsn_t lsn ;
2011-05-06 06:54:07 +04:00
xfs_lsn_t target ;
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
long tout ;
2011-05-06 06:54:05 +04:00
int stuck = 0 ;
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
int flushing = 0 ;
2011-05-06 06:54:05 +04:00
int count = 0 ;
2005-04-17 02:20:36 +04:00
2011-09-30 08:45:03 +04:00
/*
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
* If we encountered pinned items or did not finish writing out all
* buffers the last time we ran , force the log first and wait for it
* before pushing again .
2011-09-30 08:45:03 +04:00
*/
2018-03-08 01:59:39 +03:00
if ( ailp - > ail_log_flush & & ailp - > ail_last_pushed_lsn = = 0 & &
( ! list_empty_careful ( & ailp - > ail_buf_list ) | |
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
xfs_ail_min_lsn ( ailp ) ) ) {
2018-03-08 01:59:39 +03:00
ailp - > ail_log_flush = 0 ;
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
2015-10-12 10:21:22 +03:00
XFS_STATS_INC ( mp , xs_push_ail_flush ) ;
2011-09-30 08:45:03 +04:00
xfs_log_force ( mp , XFS_LOG_SYNC ) ;
}
2018-03-08 01:59:39 +03:00
spin_lock ( & ailp - > ail_lock ) ;
2012-06-28 14:52:56 +04:00
2018-03-08 01:59:39 +03:00
/* barrier matches the ail_target update in xfs_ail_push() */
2012-06-28 14:52:56 +04:00
smp_rmb ( ) ;
2018-03-08 01:59:39 +03:00
target = ailp - > ail_target ;
ailp - > ail_target_prev = target ;
2012-06-28 14:52:56 +04:00
2020-07-16 17:39:29 +03:00
/* we're done if the AIL is empty or our push has reached the end */
2018-03-08 01:59:39 +03:00
lip = xfs_trans_ail_cursor_first ( ailp , & cur , ailp - > ail_last_pushed_lsn ) ;
2020-07-16 17:39:29 +03:00
if ( ! lip )
2011-05-06 06:54:05 +04:00
goto out_done ;
2005-04-17 02:20:36 +04:00
2015-10-12 10:21:22 +03:00
XFS_STATS_INC ( mp , xs_push_ail ) ;
2005-04-17 02: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-05 04:13:32 +03:00
lsn = lip - > li_lsn ;
2011-05-06 06:54:06 +04:00
while ( ( XFS_LSN_CMP ( lip - > li_lsn , target ) < = 0 ) ) {
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 04:13:32 +03:00
int lock_result ;
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
2005-04-17 02:20:36 +04:00
/*
2013-08-28 15:12:03 +04:00
* Note that iop_push may unlock and reacquire the AIL lock . We
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
* rely on the AIL cursor implementation to be able to deal with
* the dropped lock .
2005-04-17 02:20:36 +04:00
*/
2017-08-09 04:21:52 +03:00
lock_result = xfsaild_push_item ( ailp , lip ) ;
2005-04-17 02: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-05 04:13:32 +03:00
case XFS_ITEM_SUCCESS :
2015-10-12 10:21:22 +03:00
XFS_STATS_INC ( mp , xs_push_ail_success ) ;
2011-10-11 19:14:11 +04:00
trace_xfs_ail_push ( lip ) ;
2018-03-08 01:59:39 +03:00
ailp - > ail_last_pushed_lsn = lsn ;
2005-04-17 02:20:36 +04:00
break ;
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
case XFS_ITEM_FLUSHING :
/*
2019-11-08 00:24:52 +03:00
* The item or its backing buffer is already being
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
* flushed . The typical reason for that is that an
* inode buffer is locked because we already pushed the
* updates to it as part of inode clustering .
*
* We do not want to to stop flushing just because lots
2019-11-08 00:24:52 +03:00
* of items are already being flushed , but we need to
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
* re - try the flushing relatively soon if most of the
2019-11-08 00:24:52 +03:00
* AIL is being flushed .
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
*/
2015-10-12 10:21:22 +03:00
XFS_STATS_INC ( mp , xs_push_ail_flushing ) ;
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
trace_xfs_ail_flushing ( lip ) ;
flushing + + ;
2018-03-08 01:59:39 +03:00
ailp - > ail_last_pushed_lsn = lsn ;
2005-04-17 02: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-05 04:13:32 +03:00
case XFS_ITEM_PINNED :
2015-10-12 10:21:22 +03:00
XFS_STATS_INC ( mp , xs_push_ail_pinned ) ;
2011-10-11 19:14:11 +04:00
trace_xfs_ail_pinned ( lip ) ;
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 04:13:32 +03:00
stuck + + ;
2018-03-08 01:59:39 +03:00
ailp - > ail_log_flush + + ;
2005-04-17 02: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-05 04:13:32 +03:00
case XFS_ITEM_LOCKED :
2015-10-12 10:21:22 +03:00
XFS_STATS_INC ( mp , xs_push_ail_locked ) ;
2011-10-11 19:14:11 +04:00
trace_xfs_ail_locked ( lip ) ;
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +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-05 04:13:32 +03:00
stuck + + ;
2005-04-17 02: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-05 04:13:32 +03:00
default :
2005-04-17 02: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-05 04:13:32 +03:00
count + + ;
2005-04-17 02: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-05 04:13:32 +03:00
/*
* Are there too many items we can ' t do anything with ?
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +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-05 04:13:32 +03:00
* 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 ;
2011-07-18 07:40:18 +04:00
lip = xfs_trans_ail_cursor_next ( ailp , & cur ) ;
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 04:13:32 +03:00
if ( lip = = NULL )
break ;
lsn = lip - > li_lsn ;
2005-04-17 02:20:36 +04:00
}
2020-07-16 17:39:29 +03:00
out_done :
2014-04-14 13:06:05 +04:00
xfs_trans_ail_cursor_done ( & cur ) ;
2018-03-08 01:59:39 +03:00
spin_unlock ( & ailp - > ail_lock ) ;
2005-04-17 02:20:36 +04:00
2018-03-08 01:59:39 +03:00
if ( xfs_buf_delwri_submit_nowait ( & ailp - > ail_buf_list ) )
ailp - > ail_log_flush + + ;
2010-02-02 02:13:42 +03:00
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
if ( ! count | | XFS_LSN_CMP ( lsn , target ) > = 0 ) {
2008-03-06 05:45:10 +03:00
/*
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
* We reached the target or the AIL is empty , so wait a bit
* longer for I / O to complete and remove pushed items from the
* AIL before we start the next scan from the start of the AIL .
2008-03-06 05:45:10 +03:00
*/
2010-01-11 14:49:58 +03:00
tout = 50 ;
2018-03-08 01:59:39 +03:00
ailp - > ail_last_pushed_lsn = 0 ;
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
} else if ( ( ( stuck + flushing ) * 100 ) / count > 90 ) {
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 04:13:32 +03:00
/*
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
* Either there is a lot of contention on the AIL or we are
* stuck due to operations in progress . " Stuck " in this case
* is defined as > 90 % of the items we tried to push were stuck .
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 04:13:32 +03:00
*
* Backoff a bit more to allow some I / O to complete before
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
* restarting from the start of the AIL . This prevents us from
* spinning on the same items , and if they are pinned will all
* the restart to issue a log force to unpin the stuck items .
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 04:13:32 +03:00
*/
2010-01-11 14:49:58 +03:00
tout = 20 ;
2018-03-08 01:59:39 +03:00
ailp - > ail_last_pushed_lsn = 0 ;
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
} else {
/*
* Assume we have more work to do in a short while .
*/
tout = 10 ;
2005-04-17 02:20:36 +04:00
}
2011-04-08 06:45:07 +04:00
2011-10-11 19:14:10 +04:00
return tout ;
}
static int
xfsaild (
void * data )
{
struct xfs_ail * ailp = data ;
long tout = 0 ; /* milliseconds */
2020-03-10 18:57:27 +03:00
unsigned int noreclaim_flag ;
2011-10-11 19:14:10 +04:00
2020-03-10 18:57:27 +03:00
noreclaim_flag = memalloc_noreclaim_save ( ) ;
2016-02-08 06:59:07 +03:00
set_freezable ( ) ;
xfs: on-stack delayed write buffer lists
Queue delwri buffers on a local on-stack list instead of a per-buftarg one,
and write back the buffers per-process instead of by waking up xfsbufd.
This is now easily doable given that we have very few places left that write
delwri buffers:
- log recovery:
Only done at mount time, and already forcing out the buffers
synchronously using xfs_flush_buftarg
- quotacheck:
Same story.
- dquot reclaim:
Writes out dirty dquots on the LRU under memory pressure. We might
want to look into doing more of this via xfsaild, but it's already
more optimal than the synchronous inode reclaim that writes each
buffer synchronously.
- xfsaild:
This is the main beneficiary of the change. By keeping a local list
of buffers to write we reduce latency of writing out buffers, and
more importably we can remove all the delwri list promotions which
were hitting the buffer cache hard under sustained metadata loads.
The implementation is very straight forward - xfs_buf_delwri_queue now gets
a new list_head pointer that it adds the delwri buffers to, and all callers
need to eventually submit the list using xfs_buf_delwi_submit or
xfs_buf_delwi_submit_nowait. Buffers that already are on a delwri list are
skipped in xfs_buf_delwri_queue, assuming they already are on another delwri
list. The biggest change to pass down the buffer list was done to the AIL
pushing. Now that we operate on buffers the trylock, push and pushbuf log
item methods are merged into a single push routine, which tries to lock the
item, and if possible add the buffer that needs writeback to the buffer list.
This leads to much simpler code than the previous split but requires the
individual IOP_PUSH instances to unlock and reacquire the AIL around calls
to blocking routines.
Given that xfsailds now also handle writing out buffers, the conditions for
log forcing and the sleep times needed some small changes. The most
important one is that we consider an AIL busy as long we still have buffers
to push, and the other one is that we do increment the pushed LSN for
buffers that are under flushing at this moment, but still count them towards
the stuck items for restart purposes. Without this we could hammer on stuck
items without ever forcing the log and not make progress under heavy random
delete workloads on fast flash storage devices.
[ Dave Chinner:
- rebase on previous patches.
- improved comments for XBF_DELWRI_Q handling
- fix XBF_ASYNC handling in queue submission (test 106 failure)
- rename delwri submit function buffer list parameters for clarity
- xfs_efd_item_push() should return XFS_ITEM_PINNED ]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:39 +04:00
2017-10-18 00:16:28 +03:00
while ( 1 ) {
2011-10-11 19:14:10 +04:00
if ( tout & & tout < = 20 )
2017-10-18 00:16:28 +03:00
set_current_state ( TASK_KILLABLE ) ;
2011-10-11 19:14:10 +04:00
else
2017-10-18 00:16:28 +03:00
set_current_state ( TASK_INTERRUPTIBLE ) ;
/*
xfs: clear ail delwri queued bufs on unmount of shutdown fs
In the typical unmount case, the AIL is forced out by the unmount
sequence before the xfsaild task is stopped. Since AIL items are
removed on writeback completion, this means that the AIL
->ail_buf_list delwri queue has been drained. This is not always
true in the shutdown case, however.
It's possible for buffers to sit on a delwri queue for a period of
time across submission attempts if said items are locked or have
been relogged and pinned since first added to the queue. If the
attempt to log such an item results in a log I/O error, the error
processing can shutdown the fs, remove the item from the AIL, stale
the buffer (dropping the LRU reference) and clear its delwri queue
state. The latter bit means the buffer will be released from a
delwri queue on the next submission attempt, but this might never
occur if the filesystem has shutdown and the AIL is empty.
This means that such buffers are held indefinitely by the AIL delwri
queue across destruction of the AIL. Aside from being a memory leak,
these buffers can also hold references to in-core perag structures.
The latter problem manifests as a generic/475 failure, reproducing
the following asserts at unmount time:
XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0,
file: fs/xfs/xfs_mount.c, line: 151
XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0,
file: fs/xfs/xfs_mount.c, line: 132
To prevent this problem, clear the AIL delwri queue as a final step
before xfsaild() exit. The !empty state should never occur in the
normal case, so add an assert to catch unexpected problems going
forward.
[dgc: add comment explaining need for xfs_buf_delwri_cancel() after
calling xfs_buf_delwri_submit_nowait().]
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-10-18 09:21:49 +03:00
* Check kthread_should_stop ( ) after we set the task state to
* guarantee that we either see the stop bit and exit or the
* task state is reset to runnable such that it ' s not scheduled
* out indefinitely and detects the stop bit at next iteration .
2017-10-18 00:16:28 +03:00
* A memory barrier is included in above task state set to
* serialize again kthread_stop ( ) .
*/
if ( kthread_should_stop ( ) ) {
__set_current_state ( TASK_RUNNING ) ;
xfs: clear ail delwri queued bufs on unmount of shutdown fs
In the typical unmount case, the AIL is forced out by the unmount
sequence before the xfsaild task is stopped. Since AIL items are
removed on writeback completion, this means that the AIL
->ail_buf_list delwri queue has been drained. This is not always
true in the shutdown case, however.
It's possible for buffers to sit on a delwri queue for a period of
time across submission attempts if said items are locked or have
been relogged and pinned since first added to the queue. If the
attempt to log such an item results in a log I/O error, the error
processing can shutdown the fs, remove the item from the AIL, stale
the buffer (dropping the LRU reference) and clear its delwri queue
state. The latter bit means the buffer will be released from a
delwri queue on the next submission attempt, but this might never
occur if the filesystem has shutdown and the AIL is empty.
This means that such buffers are held indefinitely by the AIL delwri
queue across destruction of the AIL. Aside from being a memory leak,
these buffers can also hold references to in-core perag structures.
The latter problem manifests as a generic/475 failure, reproducing
the following asserts at unmount time:
XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0,
file: fs/xfs/xfs_mount.c, line: 151
XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0,
file: fs/xfs/xfs_mount.c, line: 132
To prevent this problem, clear the AIL delwri queue as a final step
before xfsaild() exit. The !empty state should never occur in the
normal case, so add an assert to catch unexpected problems going
forward.
[dgc: add comment explaining need for xfs_buf_delwri_cancel() after
calling xfs_buf_delwri_submit_nowait().]
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2018-10-18 09:21:49 +03:00
/*
* The caller forces out the AIL before stopping the
* thread in the common case , which means the delwri
* queue is drained . In the shutdown case , the queue may
* still hold relogged buffers that haven ' t been
* submitted because they were pinned since added to the
* queue .
*
* Log I / O error processing stales the underlying buffer
* and clears the delwri state , expecting the buf to be
* removed on the next submission attempt . That won ' t
* happen if we ' re shutting down , so this is the last
* opportunity to release such buffers from the queue .
*/
ASSERT ( list_empty ( & ailp - > ail_buf_list ) | |
XFS_FORCED_SHUTDOWN ( ailp - > ail_mount ) ) ;
xfs_buf_delwri_cancel ( & ailp - > ail_buf_list ) ;
2017-10-18 00:16:28 +03:00
break ;
}
2012-06-28 14:52:56 +04:00
2018-03-08 01:59:39 +03:00
spin_lock ( & ailp - > ail_lock ) ;
2012-06-28 14:52:56 +04:00
/*
* Idle if the AIL is empty and we are not racing with a target
* update . We check the AIL after we set the task to a sleep
2018-03-08 01:59:39 +03:00
* state to guarantee that we either catch an ail_target update
2012-06-28 14:52:56 +04:00
* or that a wake_up resets the state to TASK_RUNNING .
* Otherwise , we run the risk of sleeping indefinitely .
*
2018-03-08 01:59:39 +03:00
* The barrier matches the ail_target update in xfs_ail_push ( ) .
2012-06-28 14:52:56 +04:00
*/
smp_rmb ( ) ;
if ( ! xfs_ail_min ( ailp ) & &
2020-07-16 17:39:29 +03:00
ailp - > ail_target = = ailp - > ail_target_prev & &
list_empty ( & ailp - > ail_buf_list ) ) {
2018-03-08 01:59:39 +03:00
spin_unlock ( & ailp - > ail_lock ) ;
2016-02-08 06:59:07 +03:00
freezable_schedule ( ) ;
2012-06-28 14:52:56 +04:00
tout = 0 ;
continue ;
}
2018-03-08 01:59:39 +03:00
spin_unlock ( & ailp - > ail_lock ) ;
2012-06-28 14:52:56 +04:00
if ( tout )
2016-02-08 06:59:07 +03:00
freezable_schedule_timeout ( msecs_to_jiffies ( tout ) ) ;
2012-06-28 14:52:56 +04:00
__set_current_state ( TASK_RUNNING ) ;
2011-10-11 19:14:10 +04:00
try_to_freeze ( ) ;
tout = xfsaild_push ( ailp ) ;
}
2020-03-10 18:57:27 +03:00
memalloc_noreclaim_restore ( noreclaim_flag ) ;
2011-10-11 19:14:10 +04:00
return 0 ;
2010-01-11 14:49:58 +03:00
}
2005-04-17 02:20:36 +04:00
2011-04-08 06:45:07 +04:00
/*
* This routine is called to move the tail of the AIL forward . It does this by
* trying to flush items in the AIL whose lsns are below the given
* threshold_lsn .
*
* The push is run asynchronously in a workqueue , which means the caller needs
* to handle waiting on the async flush for space to become available .
* We don ' t want to interrupt any push that is in progress , hence we only queue
2019-11-08 00:24:52 +03:00
* work if we set the pushing bit appropriately .
2011-04-08 06:45:07 +04:00
*
* We do this unlocked - we only need to know whether there is anything in the
* AIL at the time we are called . We don ' t need to access the contents of
* any of the objects , so the lock is not needed .
*/
void
2011-04-08 06:45:07 +04:00
xfs_ail_push (
2019-06-29 05:27:33 +03:00
struct xfs_ail * ailp ,
xfs_lsn_t threshold_lsn )
2011-04-08 06:45:07 +04:00
{
2019-06-29 05:27:33 +03:00
struct xfs_log_item * lip ;
2011-04-08 06:45:07 +04:00
lip = xfs_ail_min ( ailp ) ;
2018-03-08 01:59:39 +03:00
if ( ! lip | | XFS_FORCED_SHUTDOWN ( ailp - > ail_mount ) | |
XFS_LSN_CMP ( threshold_lsn , ailp - > ail_target ) < = 0 )
2011-04-08 06:45:07 +04:00
return ;
/*
* Ensure that the new target is noticed in push code before it clears
* the XFS_AIL_PUSHING_BIT .
*/
smp_wmb ( ) ;
2018-03-08 01:59:39 +03:00
xfs_trans_ail_copy_lsn ( ailp , & ailp - > ail_target , & threshold_lsn ) ;
2011-10-11 19:14:10 +04:00
smp_wmb ( ) ;
2018-03-08 01:59:39 +03:00
wake_up_process ( ailp - > ail_task ) ;
2011-04-08 06:45:07 +04:00
}
2005-04-17 02:20:36 +04:00
2011-04-08 06:45:07 +04:00
/*
* Push out all items in the AIL immediately
*/
void
xfs_ail_push_all (
struct xfs_ail * ailp )
{
xfs_lsn_t threshold_lsn = xfs_ail_max_lsn ( ailp ) ;
if ( threshold_lsn )
xfs_ail_push ( ailp , threshold_lsn ) ;
}
2012-04-23 09:58:34 +04:00
/*
* Push out all items in the AIL immediately and wait until the AIL is empty .
*/
void
xfs_ail_push_all_sync (
struct xfs_ail * ailp )
{
struct xfs_log_item * lip ;
DEFINE_WAIT ( wait ) ;
2018-03-08 01:59:39 +03:00
spin_lock ( & ailp - > ail_lock ) ;
2012-04-23 09:58:34 +04:00
while ( ( lip = xfs_ail_max ( ailp ) ) ! = NULL ) {
2018-03-08 01:59:39 +03:00
prepare_to_wait ( & ailp - > ail_empty , & wait , TASK_UNINTERRUPTIBLE ) ;
ailp - > ail_target = lip - > li_lsn ;
wake_up_process ( ailp - > ail_task ) ;
spin_unlock ( & ailp - > ail_lock ) ;
2012-04-23 09:58:34 +04:00
schedule ( ) ;
2018-03-08 01:59:39 +03:00
spin_lock ( & ailp - > ail_lock ) ;
2012-04-23 09:58:34 +04:00
}
2018-03-08 01:59:39 +03:00
spin_unlock ( & ailp - > ail_lock ) ;
2012-04-23 09:58:34 +04:00
2018-03-08 01:59:39 +03:00
finish_wait ( & ailp - > ail_empty , & wait ) ;
2012-04-23 09:58:34 +04:00
}
2020-03-25 06:10:29 +03:00
void
xfs_ail_update_finish (
struct xfs_ail * ailp ,
2020-03-25 06:10:29 +03:00
xfs_lsn_t old_lsn ) __releases ( ailp - > ail_lock )
2020-03-25 06:10:29 +03:00
{
struct xfs_mount * mp = ailp - > ail_mount ;
2020-03-25 06:10:29 +03:00
/* if the tail lsn hasn't changed, don't do updates or wakeups. */
if ( ! old_lsn | | old_lsn = = __xfs_ail_min_lsn ( ailp ) ) {
2020-03-25 06:10:29 +03:00
spin_unlock ( & ailp - > ail_lock ) ;
return ;
}
if ( ! XFS_FORCED_SHUTDOWN ( mp ) )
xlog_assign_tail_lsn_locked ( mp ) ;
if ( list_empty ( & ailp - > ail_head ) )
wake_up_all ( & ailp - > ail_empty ) ;
spin_unlock ( & ailp - > ail_lock ) ;
xfs_log_space_wake ( mp ) ;
}
2010-12-20 04:02:19 +03:00
/*
* xfs_trans_ail_update - bulk AIL insertion operation .
*
* @ xfs_trans_ail_update takes an array of log items that all need to be
* positioned at the same LSN in the AIL . If an item is not in the AIL , it will
* be added . Otherwise , it will be repositioned by removing it and re - adding
* it to the AIL . If we move the first item in the AIL , update the log tail to
* match the new minimum LSN in the AIL .
*
* This function takes the AIL lock once to execute the update operations on
* all the items in the array , and as such should not be called with the AIL
* lock held . As a result , once we have the AIL lock , we need to check each log
* item LSN to confirm it needs to be moved forward in the AIL .
*
* To optimise the insert operation , we delete all the items from the AIL in
* the first pass , moving them into a temporary list , then splice the temporary
* list into the correct position in the AIL . This avoids needing to do an
* insert operation on every item .
*
* This function must be called with the AIL lock held . The lock is dropped
* before returning .
*/
void
xfs_trans_ail_update_bulk (
struct xfs_ail * ailp ,
2011-07-18 07:40:16 +04:00
struct xfs_ail_cursor * cur ,
2010-12-20 04:02:19 +03:00
struct xfs_log_item * * log_items ,
int nr_items ,
2018-03-08 01:59:39 +03:00
xfs_lsn_t lsn ) __releases ( ailp - > ail_lock )
2010-12-20 04:02:19 +03:00
{
2019-06-29 05:27:33 +03:00
struct xfs_log_item * mlip ;
2020-03-25 06:10:29 +03:00
xfs_lsn_t tail_lsn = 0 ;
2010-12-20 04:02:19 +03:00
int i ;
LIST_HEAD ( tmp ) ;
2011-07-22 20:04:41 +04:00
ASSERT ( nr_items > 0 ) ; /* Not required, but true. */
2010-12-20 04:02:19 +03:00
mlip = xfs_ail_min ( ailp ) ;
for ( i = 0 ; i < nr_items ; i + + ) {
struct xfs_log_item * lip = log_items [ i ] ;
2018-05-09 17:47:34 +03:00
if ( test_and_set_bit ( XFS_LI_IN_AIL , & lip - > li_flags ) ) {
2010-12-20 04:02:19 +03:00
/* check if we really need to move the item */
if ( XFS_LSN_CMP ( lsn , lip - > li_lsn ) < = 0 )
continue ;
2013-11-01 08:27:18 +04:00
trace_xfs_ail_move ( lip , lip - > li_lsn , lsn ) ;
2020-03-25 06:10:29 +03:00
if ( mlip = = lip & & ! tail_lsn )
tail_lsn = lip - > li_lsn ;
2010-12-20 04:02:19 +03:00
xfs_ail_delete ( ailp , lip ) ;
} else {
2013-11-01 08:27:18 +04:00
trace_xfs_ail_insert ( lip , 0 , lsn ) ;
2010-12-20 04:02:19 +03:00
}
lip - > li_lsn = lsn ;
list_add ( & lip - > li_ail , & tmp ) ;
}
2011-07-22 20:04:41 +04:00
if ( ! list_empty ( & tmp ) )
xfs_ail_splice ( ailp , cur , & tmp , lsn ) ;
2010-12-20 04:02:19 +03:00
2020-03-25 06:10:29 +03:00
xfs_ail_update_finish ( ailp , tail_lsn ) ;
2020-05-02 02:00:54 +03:00
}
/* Insert a log item into the AIL. */
void
xfs_trans_ail_insert (
struct xfs_ail * ailp ,
struct xfs_log_item * lip ,
xfs_lsn_t lsn )
{
spin_lock ( & ailp - > ail_lock ) ;
xfs_trans_ail_update_bulk ( ailp , NULL , & lip , 1 , lsn ) ;
2010-12-20 04:02:19 +03:00
}
2020-03-25 06:10:29 +03:00
/*
* Delete one log item from the AIL .
*
* If this item was at the tail of the AIL , return the LSN of the log item so
* that we can use it to check if the LSN of the tail of the log has moved
* when finishing up the AIL delete process in xfs_ail_update_finish ( ) .
*/
xfs_lsn_t
2017-04-21 21:24:42 +03:00
xfs_ail_delete_one (
struct xfs_ail * ailp ,
xfs: Properly retry failed inode items in case of error during buffer writeback
When a buffer has been failed during writeback, the inode items into it
are kept flush locked, and are never resubmitted due the flush lock, so,
if any buffer fails to be written, the items in AIL are never written to
disk and never unlocked.
This causes unmount operation to hang due these items flush locked in AIL,
but this also causes the items in AIL to never be written back, even when
the IO device comes back to normal.
I've been testing this patch with a DM-thin device, creating a
filesystem larger than the real device.
When writing enough data to fill the DM-thin device, XFS receives ENOSPC
errors from the device, and keep spinning on xfsaild (when 'retry
forever' configuration is set).
At this point, the filesystem can not be unmounted because of the flush locked
items in AIL, but worse, the items in AIL are never retried at all
(once xfs_inode_item_push() will skip the items that are flush locked),
even if the underlying DM-thin device is expanded to the proper size.
This patch fixes both cases, retrying any item that has been failed
previously, using the infra-structure provided by the previous patch.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2017-08-09 04:21:50 +03:00
struct xfs_log_item * lip )
2017-04-21 21:24:42 +03:00
{
struct xfs_log_item * mlip = xfs_ail_min ( ailp ) ;
2020-03-25 06:10:29 +03:00
xfs_lsn_t lsn = lip - > li_lsn ;
2017-04-21 21:24:42 +03:00
trace_xfs_ail_delete ( lip , mlip - > li_lsn , lip - > li_lsn ) ;
xfs_ail_delete ( ailp , lip ) ;
2018-05-09 17:47:34 +03:00
clear_bit ( XFS_LI_IN_AIL , & lip - > li_flags ) ;
2017-04-21 21:24:42 +03:00
lip - > li_lsn = 0 ;
2020-03-25 06:10:29 +03:00
if ( mlip = = lip )
return lsn ;
return 0 ;
2017-04-21 21:24:42 +03:00
}
2010-12-20 04:03:17 +03:00
void
2017-04-21 21:24:42 +03:00
xfs_trans_ail_delete (
struct xfs_log_item * lip ,
2020-03-25 06:10:29 +03:00
int shutdown_type )
2010-12-20 04:03:17 +03:00
{
2020-05-06 23:25:23 +03:00
struct xfs_ail * ailp = lip - > li_ailp ;
2018-03-08 01:59:39 +03:00
struct xfs_mount * mp = ailp - > ail_mount ;
2020-03-25 06:10:29 +03:00
xfs_lsn_t tail_lsn ;
2010-12-20 04:03:17 +03:00
2020-05-06 23:25:23 +03:00
spin_lock ( & ailp - > ail_lock ) ;
2018-05-09 17:47:34 +03:00
if ( ! test_bit ( XFS_LI_IN_AIL , & lip - > li_flags ) ) {
2018-03-08 01:59:39 +03:00
spin_unlock ( & ailp - > ail_lock ) ;
2020-05-06 23:27:04 +03:00
if ( shutdown_type & & ! XFS_FORCED_SHUTDOWN ( mp ) ) {
2017-04-21 21:24:42 +03:00
xfs_alert_tag ( mp , XFS_PTAG_AILDELETE ,
" %s: attempting to delete a log item that is not in the AIL " ,
__func__ ) ;
xfs_force_shutdown ( mp , shutdown_type ) ;
2010-12-20 04:03:17 +03:00
}
2017-04-21 21:24:42 +03:00
return ;
2010-12-20 04:03:17 +03:00
}
2020-05-06 23:27:04 +03:00
/* xfs_ail_update_finish() drops the AIL lock */
2020-06-30 00:49:15 +03:00
xfs_clear_li_failed ( lip ) ;
2020-03-25 06:10:29 +03:00
tail_lsn = xfs_ail_delete_one ( ailp , lip ) ;
xfs_ail_update_finish ( ailp , tail_lsn ) ;
2010-12-20 04:03:17 +03:00
}
2005-04-17 02: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-05 04:13:32 +03:00
int
2005-04-17 02:20:36 +04:00
xfs_trans_ail_init (
xfs_mount_t * mp )
{
2008-10-30 09:38:26 +03:00
struct xfs_ail * ailp ;
ailp = kmem_zalloc ( sizeof ( struct xfs_ail ) , KM_MAYFAIL ) ;
if ( ! ailp )
2014-06-25 08:58:08 +04:00
return - ENOMEM ;
2008-10-30 09:38:26 +03:00
2018-03-08 01:59:39 +03:00
ailp - > ail_mount = mp ;
INIT_LIST_HEAD ( & ailp - > ail_head ) ;
INIT_LIST_HEAD ( & ailp - > ail_cursors ) ;
spin_lock_init ( & ailp - > ail_lock ) ;
INIT_LIST_HEAD ( & ailp - > ail_buf_list ) ;
init_waitqueue_head ( & ailp - > ail_empty ) ;
2011-10-11 19:14:10 +04:00
2018-03-08 01:59:39 +03:00
ailp - > ail_task = kthread_run ( xfsaild , ailp , " xfsaild/%s " ,
2019-11-05 00:58:40 +03:00
ailp - > ail_mount - > m_super - > s_id ) ;
2018-03-08 01:59:39 +03:00
if ( IS_ERR ( ailp - > ail_task ) )
2011-10-11 19:14:10 +04:00
goto out_free_ailp ;
2008-10-30 09:38:39 +03:00
mp - > m_ail = ailp ;
return 0 ;
2011-10-11 19:14:10 +04:00
out_free_ailp :
kmem_free ( ailp ) ;
2014-06-25 08:58:08 +04:00
return - ENOMEM ;
[XFS] Move AIL pushing into it's own thread
When many hundreds to thousands of threads all try to do simultaneous
transactions and the log is in a tail-pushing situation (i.e. full), we
can get multiple threads walking the AIL list and contending on the AIL
lock.
The AIL push is, in effect, a simple I/O dispatch algorithm complicated by
the ordering constraints placed on it by the transaction subsystem. It
really does not need multiple threads to push on it - even when only a
single CPU is pushing the AIL, it can push the I/O out far faster that
pretty much any disk subsystem can handle.
So, to avoid contention problems stemming from multiple list walkers, move
the list walk off into another thread and simply provide a "target" to
push to. When a thread requires a push, it sets the target and wakes the
push thread, then goes to sleep waiting for the required amount of space
to become available in the log.
This mechanism should also be a lot fairer under heavy load as the waiters
will queue in arrival order, rather than queuing in "who completed a push
first" order.
Also, by moving the pushing to a separate thread we can do more
effectively overload detection and prevention as we can keep context from
loop iteration to loop iteration. That is, we can push only part of the
list each loop and not have to loop back to the start of the list every
time we run. This should also help by reducing the number of items we try
to lock and/or push items that we cannot move.
Note that this patch is not intended to solve the inefficiencies in the
AIL structure and the associated issues with extremely large list
contents. That needs to be addresses separately; parallel access would
cause problems to any new structure as well, so I'm only aiming to isolate
the structure from unbounded parallelism here.
SGI-PV: 972759
SGI-Modid: xfs-linux-melb:xfs-kern:30371a
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
2008-02-05 04:13:32 +03:00
}
void
xfs_trans_ail_destroy (
xfs_mount_t * mp )
{
2008-10-30 09:38:26 +03:00
struct xfs_ail * ailp = mp - > m_ail ;
2018-03-08 01:59:39 +03:00
kthread_stop ( ailp - > ail_task ) ;
2008-10-30 09:38:26 +03:00
kmem_free ( ailp ) ;
2005-04-17 02:20:36 +04:00
}