Re: Huge memory leak in virtio, see kvm-Bugs-2989366

[Michael Tokarev <mjt@tls.msk.ru>]

21.04.2010 05:58, Ryan Harper wrote:
> * Leszek Urbanski<tygrys@moo.pl>  [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