From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Maik Wessler <maik.wessler@yahoo.com>,
Maik Wessler <maik@mwessler.net>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: qemu-system-i386: memory leak?
Date: Wed, 2 Jan 2013 17:09:22 +0100 [thread overview]
Message-ID: <50E45BB2.6010601@citrix.com> (raw)
In-Reply-To: <1357142302.5668.92.camel@zakaz.uk.xensource.com>
On 02/01/13 16:58, Ian Campbell wrote:
> On Mon, 2012-12-31 at 13:06 +0000, Roger Pau Monné wrote:
>> On 26/12/12 11:46, Maik Wessler wrote:
>>> Hi all,
>>>
>>> I am using xen-4.2-testing.hg on debian 6.0.6 (x86_64) with Kernel
>>> 3.4.15 (tmem enabled).
>
> Why 3.4.15? Would be good to either use the distro kernel or keep up
> with the upstream stable branch.
>
>> Problem is that the /usr/lib/xen/bin/qemu-system-i386
>>> use more and more memory. After one week uptime (depends on memory) the
>>> machine starts to swap...
> [...]
>>> total 424016K
>>>
>>>
>>> Can anyone help?
>>
>> I've just posted a bug fix for a memory leak in Qemu Xen PV disk
>> backend, you can take a look at the patch at:
>> http://lists.nongnu.org/archive/html/qemu-devel/2012-12/msg03677.html.
>
> The pmap doesn't appear to show any open backing devices for a disk so
> I'm guessing this isn't in use?
Qemu doesn't use mmap to open the disk file, so I guess it's normal that
the backing file is not shown in the pmap trace (that's more or less the
same map I get from qemu with one qdisk attached to a DomU).
> Given that this is a PV guest and I can see -nographic on the qemu
> command line I'm not what qemu is doing -- can we see the guest
> configuration please? "xl -vvv create" logs would be useful too.
>
>> There's also a memory leak in the linux gntdev device which is used by
>> Qemu, you should also take a look at the following linux kernel patch
>> http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=a67baeb77375199bbd842fa308cb565164dd1f19.
>>
>
> This is possible.
>
> If it doesn't turn out to be this then one approach might be to arrange
> to run qemu under valgrind for a little bit and see if anything springs
> out.
>
> You'd probably need at least r13081 of Valgrind's SVN trunk to remove
> all the noise due to hypercalls.
I've run Qemu blkback for PV guests (qdisk) under Valgrind, and found
only the leak that the above patch fixes.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
prev parent reply other threads:[~2013-01-02 16:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-26 10:46 qemu-system-i386: memory leak? Maik Wessler
2012-12-31 13:06 ` Roger Pau Monné
2013-01-02 15:58 ` Ian Campbell
2013-01-02 16:09 ` Roger Pau Monné [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50E45BB2.6010601@citrix.com \
--to=roger.pau@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=maik.wessler@yahoo.com \
--cc=maik@mwessler.net \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.