qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [libvirt] [PATCH] qemu: Drop qemuDomainMemoryLimit


From: Andreas Färber
Subject: Re: [Qemu-devel] [libvirt] [PATCH] qemu: Drop qemuDomainMemoryLimit
Date: Fri, 09 Aug 2013 18:32:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7

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.
> 
> The only practical way of doing this would be to have QEMU gracefully
> handle malloc() == NULL so that you could set a limit and gracefully
> 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

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]