14.06.2010 13:37, Dave Walker wrote:
Changing to libvirt as commentary here, and on the upstream bug report by Cole indicate a fix has been commit that improves this performance.
Um. This is not that simple, apparently. I did some tests after this bug were discussed/mentioned last time, and see absolutely no difference between 512 and 1M dd block size. Well, there IS some difference, like several percents, but it is still very slow, and is doing nothing -- the machine is 99% idle while saving the state. Also, when using, say, gzip or lzop in place of dd (both of them perform input in units larger than 512 bytes), it is still as slow. strace shows one of kvm threads is slowly poking eventfd all the time, while others are doing right to nothing. It looks like some bad timing issue. The fact that changing block size helps sometimes - I think it's because the improvements of timing (mix-n-match), not because of real improvements.
** Package changed: qemu-kvm (Ubuntu) => libvirt (Ubuntu)
In any way, the problem is definitely NOT in libvirt, since the same slowness is observed without libvirt. Thanks! /mjt
