From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49868) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7pcD-0001JA-DD for qemu-devel@nongnu.org; Fri, 09 Aug 2013 12:32:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7pc6-0007Ys-4R for qemu-devel@nongnu.org; Fri, 09 Aug 2013 12:32:37 -0400 Received: from cantor2.suse.de ([195.135.220.15]:39570 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7pc5-0007Yg-VH for qemu-devel@nongnu.org; Fri, 09 Aug 2013 12:32:30 -0400 Message-ID: <5205199A.6090602@suse.de> Date: Fri, 09 Aug 2013 18:32:26 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <5204EB16.8020801@redhat.com> <20130809131759.GB2868@redhat.com> <5204EEA9.1010002@redhat.com> <87haeysvnk.fsf@codemonkey.ws> In-Reply-To: <87haeysvnk.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [libvirt] [PATCH] qemu: Drop qemuDomainMemoryLimit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: libvir-list@redhat.com, Michal Privoznik , QEMU Developers Am 09.08.2013 17:58, schrieb Anthony Liguori: > Even if we had an algorithm for calculating memory overhead (we don't), > glibc will still introduce uncertainty since malloc(size) doesn't > translate to allocating size bytes from the kernel. When you throw in > fragmentation too it becomes extremely hard to predict. >=20 > The only practical way of doing this would be to have QEMU gracefully > handle malloc() =3D=3D NULL so that you could set a limit and gracefull= y > degrade. We don't though so setting a limit is likely to get you in > trouble. FWIW my QOM realize work is targetted at reducing likelihood that device_add blows up QEMU due to OOM in object_new(). But before I can change qdev-monitor.c I still need to tweak core QOM to either get at TypeImpl::instance_size or to introduce an object_try_new() function using g_try_malloc0() rather than g_malloc0(). That's where proper child struct composition comes into play. The major variance in runtime memory consumption was so far attributed to block and network I/O, without ever getting exact proof points... Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg