aboutsummaryrefslogtreecommitdiffstats
path: root/fs/xfs/xfs_mount.c
diff options
context:
space:
mode:
authorDavid Chinner <dgc@sgi.com>2008-02-04 20:13:32 -0500
committerLachlan McIlroy <lachlan@redback.melbourne.sgi.com>2008-02-07 02:22:51 -0500
commit249a8c1124653fa90f3a3afff869095a31bc229f (patch)
treee0681990b5b61155a64a9fd3c0cf73d4d6bb4ce5 /fs/xfs/xfs_mount.c
parent4576758db5817a91b8974c696247d459dc653db2 (diff)
[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>
Diffstat (limited to 'fs/xfs/xfs_mount.c')
-rw-r--r--fs/xfs/xfs_mount.c6
1 files changed, 0 insertions, 6 deletions
diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index 766c01670b2c..6409b3762995 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -136,15 +136,9 @@ xfs_mount_init(void)
136 mp->m_flags |= XFS_MOUNT_NO_PERCPU_SB; 136 mp->m_flags |= XFS_MOUNT_NO_PERCPU_SB;
137 } 137 }
138 138
139 spin_lock_init(&mp->m_ail_lock);
140 spin_lock_init(&mp->m_sb_lock); 139 spin_lock_init(&mp->m_sb_lock);
141 mutex_init(&mp->m_ilock); 140 mutex_init(&mp->m_ilock);
142 mutex_init(&mp->m_growlock); 141 mutex_init(&mp->m_growlock);
143 /*
144 * Initialize the AIL.
145 */
146 xfs_trans_ail_init(mp);
147
148 atomic_set(&mp->m_active_trans, 0); 142 atomic_set(&mp->m_active_trans, 0);
149 143
150 return mp; 144 return mp;