http://bugzilla.opensuse.org/show_bug.cgi?id=1148562
http://bugzilla.opensuse.org/show_bug.cgi?id=1148562#c6
--- Comment #6 from Nikolay Borisov
By reducing the qemu snapshot saving time (by increasing QEMU_COMPRESS_THREADS from 3 to 5), the problem is gone.
So, it looks like a qemu problem. Not sure if we could have it in real life? @Nicolay, what do you think?
Be that is it may it doesn't preclude a "bug" in btrfs' code. Essentially the softlockup detector kicks in when it detects a particular CPU hasn't yielded for 24 seconds ( or whatever is the configured threshold). It's a fact that the code dealing with send with a parent snapshot involved doesn't contain a cond_resched so in case where large trees have to be compared the softlockup detector can kick in. For multicore systems this is not really an issue - it just means a particular CPU will be hogged for as long as tree comparison lasts. By increasing the the QEMU_COMPRESS_THREADS you make the comparison faster so the soft lock up doesn't trigger. But according to the kernel programming paradigms the softlock detector shouldn't have kicked in the first place. Given this then I consider the patch valid and needed. So I'd still like you to test it with QEMU_COMPRESS_THREADS set to 3 or even 1-2 so that we are sure even if the machine is dead-slow the code is acting appropriately. -- You are receiving this mail because: You are on the CC list for the bug.