21.04.2010 05:58, Ryan Harper wrote:
* Leszek Urbanski<tygrys@xxxxxx> [2010-04-20 17:37]:
Hi,
this is a follow-up to bug 2989366:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2989366&group_id=180599
after extensive debugging with the guys on #kvm it turns out that the leak is
in the qemu-kvm userland process, in virtio-blk.
[]
Is that qemu-kvm 0.12.3 compiled from source? or using the distro
package?
(i'm not the OP, but we talked with him on irc about the issue)
It's a debian package of qemu-kvm. There are a couple of cosmetic
and unrelated patches applied to it, with one important to fix the
large iovecs issue. See
http://git.debian.org/?p=collab-maint/qemu-kvm.git;a=tree;f=debian/patches;h=25ae313db327faa0559016e40fa6161018eb49f4;hb=caa82cbb176403e88128b4fe2698ff192ea10891
for the complete set of patches in there (it's debian/patches
directory in http://git.debian.org/?p=collab-maint/qemu-kvm.git ,
in v0.12.3+dfsg-4 branch). The only interesting patch in there
is the avoid_creating_too_large_iovecs_in_multiwrite_merge.patch
one, the rest are not relevant.
If you drop the -smp 4 part, you could also try plain qemu to eliminate
if there was a qemu-kvm merge issue.
So basically, upstream qemu now works as good
as qemu-kvm for non-smp guests?
Also, if you switch to a different guest do you still see the same leak?
This should help determine if the virtio-blk front end is part of the
issue.
There are only a few guests which are affected. So far it is not
really clear what differs them from others: a reinstall of a new
guest with the same components and doing same functions will not
necessary show the leak.
Thanks!
/mjt
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
