On Wed, Aug 1, 2012 at 7:21 PM, Mitch Harder <[email protected]> wrote: > On Wed, Aug 1, 2012 at 3:25 PM, Josef Bacik <[email protected]> wrote: >> We need an smb_mb() before waitqueue_active to avoid missing wakeups. >> Before Mitch was hitting a deadlock between the ordered flushers and the >> transaction commit because the ordered flushers were waiting for more refs >> and were never woken up, so those smp_mb()'s are the most important. >> Everything else I added for correctness sake and to avoid getting bitten by >> this again somewhere else. Thanks, >> > > This patch seems to make it tougher to hit a deadlock, but I'm still > encountering intermittent deadlocks using this patch when running > multiple rsync threads. > > I've also tested "Patch 2", and that has me hitting a deadlock even > quicker (when starting several copying threads). > > I also found a slight performance hit using this patch. On a 3.4.6 > kernel (merged with the 3.5_rc for-linus branch), I would typically > complete my rsync test in ~265 seconds. Also, I can't recall hitting > a deadlock on the 3.4.6 kernel (with 3.5_rc for-linus). When using > this patch, the test would take ~310 seconds (when it didn't hit a > deadlock). >
I've bisected my deadlock back to: Btrfs: hooks for qgroup to record delayed refs (commit 546adb0d). This issue may be the same problem Alexander Block is discussing in another thread on the Btrfs Mailing List: http://article.gmane.org/gmane.comp.file-systems.btrfs/19028 I'm using multiple rsync threads instead of the new send/receive function. But we're both hitting deadlocks that bisect back to the same commit. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
