xfs
[Top] [All Lists]

[PATCH 2/2] xfs: mark the xfs-alloc workqueue as high priority

To: Eric Sandeen <sandeen@xxxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
Subject: [PATCH 2/2] xfs: mark the xfs-alloc workqueue as high priority
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Fri, 09 Jan 2015 12:12:04 -0600
Cc: Tejun Heo <tj@xxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <54B01927.2010506@xxxxxxxxxx>
References: <54B01927.2010506@xxxxxxxxxx>
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;
 

<Prev in Thread] Current Thread [Next in Thread>