From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:50801)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Paul_Brook@mentor.com>) id 1Rw16j-0005sy-Ow
	for qemu-devel@nongnu.org; Fri, 10 Feb 2012 19:46:30 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <Paul_Brook@mentor.com>) id 1Rw16i-00077E-Qo
	for qemu-devel@nongnu.org; Fri, 10 Feb 2012 19:46:29 -0500
Received: from relay1.mentorg.com ([192.94.38.131]:56840)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Paul_Brook@mentor.com>) id 1Rw16i-000771-KF
	for qemu-devel@nongnu.org; Fri, 10 Feb 2012 19:46:28 -0500
From: Paul Brook <paul@codesourcery.com>
Date: Sat, 11 Feb 2012 00:46:23 +0000
References: <CAEH94LgVhABxRxwQqxwUY_mVVUoXuX+zz34YwKHLVRjXgOfbxg@mail.gmail.com>
	<201202102325.54423.paul@codesourcery.com>
	<4F35B555.2050308@suse.de>
In-Reply-To: <4F35B555.2050308@suse.de>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-6"
Content-Transfer-Encoding: 7bit
Message-Id: <201202110046.24433.paul@codesourcery.com>
Subject: Re: [Qemu-devel] Memory: how to determine the max memory size of
	one VM?
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Andreas =?utf-8?q?F=C3=A4rber?= <afaerber@suse.de>
Cc: Zhi Yong Wu <zwu.kernel@gmail.com>, Stefan Hajnoczi <stefanha@gmail.com>, Alexander Graf <agraf@suse.de>, qemu-devel@nongnu.org, Stefan Weil <sw@weilnetz.de>

> Am 11.02.2012 00:25, schrieb Paul Brook:
> >> ii) Some tracing of mine indicates QEMU has a highly dynamic memory
> >> usage during runtime, be it due to network layer, block layer or
> >> whatever exactly.
> > 
> > We do? Significant compared to the size of guest ram?  That sounds like a
> > bug.
> 
> Attached is a gnuplot from a simpletrace trace file while installing a
> SLES 11 SP2 Release Candidate over slirp to virtio with -m 8G on an 8
> GiB host (post-1.0 master).
> 
> It's not fully scientifically correct (it doesn't take into account
> memory allocations not traced by QEMU itself, like pthreads) but it
> suggests that after the initial surge to ~8.7 GB we have a fluctuation
> of ~0.2 GB for 8 GiB guest RAM. It's larger than I'd expect at least.
> 
> Since the user was close to the limit, this lead to an abort. In their
> case it was a pthread_create() that failed, and we used tap + virtio.

Hmm, yes, we're clearly allocating some very large buffers somewhere.

Paul