From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@novell.com>
Cc: anthony.perard@citrix.com, Charles Arnold <CARNOLD@novell.com>,
xen-devel@lists.xensource.com,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: Xen 4.0.1 "xc_map_foreign_batch: mmap failed: Cannot allocate memory"
Date: Fri, 17 Dec 2010 10:06:05 +0000 [thread overview]
Message-ID: <C930E68D.2968E%keir@xen.org> (raw)
In-Reply-To: <4D0B3A000200007800028A0C@vpn.id2.novell.com>
On 17/12/2010 09:22, "Jan Beulich" <JBeulich@novell.com> wrote:
>> If we can work out and detect this limit, perhaps 64-bit qemu-dm could have
>> a mapping cache similar to 32-bit qemu-dm, limited to some fraction of the
>> detected mapping limit. And/or, on mapping failure, we could reclaim
>> resources by simply zapping the existing cached mappings. Seems there's a
>> few options. I don't really maintain qemu-dm myself -- you might get some
>> help from Ian Jackson, Stefano, or Anthony Perard if you need more advice.
>
> Looking forward to their comments.
One issue with a failure path added to just the 'mapping cache' is that, if
we have hit some hard mapping or VM limit for this process, various other
syscalls in other qemu subsystems may also start to fail. If we let
ourselves get to this point, it seems to be that handling it robustly might
be difficult. OTOH, it shouldn't be hard to do a lot better than we are
currently. :-)
-- Keir
next prev parent reply other threads:[~2010-12-17 10:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-16 19:23 Xen 4.0.1 "xc_map_foreign_batch: mmap failed: Cannot allocate memory" Charles Arnold
2010-12-16 20:33 ` Keir Fraser
2010-12-16 20:44 ` Charles Arnold
2010-12-16 20:54 ` Keir Fraser
2010-12-17 9:22 ` Jan Beulich
2010-12-17 10:06 ` Keir Fraser [this message]
2011-01-05 14:37 ` Stefano Stabellini
2011-01-05 15:30 ` Jan Beulich
2011-01-05 16:22 ` Stefano Stabellini
2011-01-05 16:33 ` Jan Beulich
2011-01-05 17:48 ` Stefano Stabellini
2011-01-05 18:09 ` Jan Beulich
2011-01-05 17:17 ` Charles Arnold
2011-01-06 16:50 ` Stefano Stabellini
2011-01-06 17:14 ` Charles Arnold
-- strict thread matches above, loose matches on Subject: below --
2011-01-05 18:10 Jan Beulich
2011-01-06 20:49 Charles Arnold
2011-01-07 9:35 Jan Beulich
2011-01-07 11:18 ` Stefano Stabellini
2011-01-07 12:37 ` Jan Beulich
2011-01-10 11:11 ` Stefano Stabellini
2011-01-07 17:03 ` Charles Arnold
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=C930E68D.2968E%keir@xen.org \
--to=keir@xen.org \
--cc=CARNOLD@novell.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@novell.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=anthony.perard@citrix.com \
--cc=xen-devel@lists.xensource.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).