I had a case reported where a system under high stress
got deadlocked. A btree split was handed off to the xfs
allocation workqueue, and it is holding the xfs_ilock
exclusively. However, other xfs_end_io workers are
not running, because they are waiting for that lock.
As a result, the xfs allocation workqueue never gets
run, and everything grinds to a halt.
To be honest, it's not clear to me how the workqueue
subsystem manages this sort of thing. But in testing,
making the allocation workqueue high priority so that
it gets added to the front of the pending work list,
resolves the problem. We did similar things for
the xfs-log workqueues, for similar reasons.
Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
---
(slight whitespace shift is to fit in 80 cols, sorry!)
diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index e5bdca9..9c549e1 100644
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs/xfs_super.c
@@ -874,7 +874,7 @@ xfs_init_mount_workqueues(
goto out_destroy_log;
mp->m_alloc_workqueue = alloc_workqueue("xfs-alloc/%s",
- WQ_MEM_RECLAIM|WQ_FREEZABLE, 0, mp->m_fsname);
+ WQ_MEM_RECLAIM|WQ_FREEZABLE|WQ_HIGHPRI, 0, mp->m_fsname);
if (!mp->m_alloc_workqueue)
goto out_destroy_eofblocks;
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
