From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stefan Hajnoczi <stefanha@gmail.com>
Subject: Re: How to diagnose memory leak in kvm-qemu-0.14.0?
Date: Fri, 20 May 2011 14:16:05 +0100
Message-ID: <BANLkTimGKv90+JsgpS=zh8ZdNYpyismQpw@mail.gmail.com>
References: <20110518164429.GA20927@bytemark.co.uk>
	<BANLkTimq2S3a=BbDJvxkeET9pK64ybKEiw@mail.gmail.com>
	<20110519115734.GB3490@bytemark.co.uk>
	<BANLkTiks_sGBSnEJ9YhY=wXqn70cvyi-vw@mail.gmail.com>
	<20110520114707.GG27422@bytemark.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: kvm@vger.kernel.org
To: Steve Kemp <steve@bytemark.co.uk>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-gw0-f46.google.com ([74.125.83.46]:36587 "EHLO
	mail-gw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932947Ab1ETNQG convert rfc822-to-8bit (ORCPT
	<rfc822;kvm@vger.kernel.org>); Fri, 20 May 2011 09:16:06 -0400
Received: by gwaa18 with SMTP id a18so1287852gwa.19
        for <kvm@vger.kernel.org>; Fri, 20 May 2011 06:16:05 -0700 (PDT)
In-Reply-To: <20110520114707.GG27422@bytemark.co.uk>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Fri, May 20, 2011 at 12:47 PM, Steve Kemp <steve@bytemark.co.uk> wro=
te:
> On Fri May 20, 2011 at 12:01:58 +0100, Stefan Hajnoczi wrote:
>
>> > =A0wget http://mirror.bytemark.co.uk/misc/test-files/500M
>> > =A0while true; do cp 500M foo.img; rm foo.img; sleep 2; done
>> >
>> > =A0"top" shows the virt memory growing to >1gb in under two minute=
s.
>>
>> Were you able to track down the culprit?
>
> =A0Yes, or at least confirm my suspicion. =A0The virtio block device
> =A0is the source of the leak.
>
> =A0Host kernel: 2.6.32.15
> =A0Guest Kernel: linux-2.6.32.23
>
> =A0Leaking case:
>
> =A0opt/kvm2/bin/qemu-system-x86_64 -m 500 \
> =A0 =A0-drive file=3D/machines/kvm2/jail/root_fs,if=3Dvirtio,cache=3D=
off
>
> =A0Non leaking case:
>
> =A0 /opt/kvm/current/bin/qemu-system-x86_64 -m 500 \
> =A0 =A0 -drive file=3D/machines/kvm1/jail/root_fs,cache=3Doff ..
>
> =A0The leak occurs with both KVM 0.12.5 and 0.14.0.
>
> =A0I've had a quick read of hw/virtio-blk.c but didn't see anything
> =A0glaringly obvious. =A0I'll need to trace through the code, drink m=
ore
> =A0coffee, or get lucky to narrow it down further.

Enabling the memory allocation trace events and adding the
__builtin_return_address() to them should provide enough information
to catch the caller who is leaking memory.

Stefan