| To: | Dave Chinner <david@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 0/3] xfs: allocation worker causes freelist buffer lock hang |
| From: | Mark Tinguely <tinguely@xxxxxxx> |
| Date: | Thu, 20 Sep 2012 08:49:55 -0500 |
| Cc: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20120919233435.GF31501@dastard> |
| References: | <20120919163133.097340199@xxxxxxx> <20120919233435.GF31501@dastard> |
| User-agent: | Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0 |
On 09/19/12 18:34, Dave Chinner wrote: I suspect the only way to fix this is to re-use the old workqueue method of avoiding blocking on the workqueue indefinitely. That is, if we fail to get the lock in this case, we return with EGAIN and requeue the work. __xfs_alloc_vextent() and xfs_alloc_fix_freelist() already have trylock support, so this should be fairly easy to do. If I also convert the work to delayed work, I can easily add a backoff that will prevent busy looping on the workqueue. I'll have a quick look at this and see what falls out.... Okay. Many of these paths are not using an allocator worker (userdata==0) and/or the loops are done within a new transaction. --Mark. |
| Previous by Date: | [PATCH 6/6] xfs: Make inode32 a remountable option, Carlos Maiolino |
|---|---|
| Next by Date: | Re: [PATCH 0/6 V4] inode32/inode64 allocation changes, Brian Foster |
| Previous by Thread: | Re: [PATCH 0/3] xfs: allocation worker causes freelist buffer lock hang, Dave Chinner |
| Next by Thread: | Re: [PATCH 0/3] xfs: allocation worker causes freelist buffer lock hang, Dave Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |