From: "Andreas Färber" <afaerber@suse.de>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: libvir-list@redhat.com, Michal Privoznik <mprivozn@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [libvirt] [PATCH] qemu: Drop qemuDomainMemoryLimit
Date: Fri, 09 Aug 2013 18:32:26 +0200 [thread overview]
Message-ID: <5205199A.6090602@suse.de> (raw)
In-Reply-To: <87haeysvnk.fsf@codemonkey.ws>
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
prev parent reply other threads:[~2013-08-09 16:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ad6173415eb6c51c95645e42b4bafa67cac39986.1376052970.git.mprivozn@redhat.com>
[not found] ` <5204EB16.8020801@redhat.com>
[not found] ` <20130809131759.GB2868@redhat.com>
2013-08-09 13:29 ` [Qemu-devel] [libvirt] [PATCH] qemu: Drop qemuDomainMemoryLimit Michal Privoznik
2013-08-09 15:58 ` Anthony Liguori
2013-08-09 16:29 ` Daniel P. Berrange
2013-08-19 8:29 ` Michal Privoznik
2013-08-19 9:06 ` Daniel P. Berrange
2013-08-19 10:06 ` Michal Privoznik
2013-08-09 16:32 ` Andreas Färber [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=5205199A.6090602@suse.de \
--to=afaerber@suse.de \
--cc=anthony@codemonkey.ws \
--cc=libvir-list@redhat.com \
--cc=mprivozn@redhat.com \
--cc=qemu-devel@nongnu.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.