From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tokarev Subject: Re: Huge memory leak in virtio, see kvm-Bugs-2989366 Date: Wed, 21 Apr 2010 10:08:20 +0400 Message-ID: <4BCE9654.2030604@msgid.tls.msk.ru> References: <20100420222956.GA13218@moo.pl> <20100421015803.GV24351@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Leszek Urbanski , kvm@vger.kernel.org To: Ryan Harper Return-path: Received: from isrv.corpit.ru ([81.13.33.159]:47679 "EHLO isrv.corpit.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752231Ab0DUGIW (ORCPT ); Wed, 21 Apr 2010 02:08:22 -0400 In-Reply-To: <20100421015803.GV24351@us.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: 21.04.2010 05:58, Ryan Harper wrote: > * Leszek Urbanski [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