From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Xen 4.0.1 "xc_map_foreign_batch: mmap failed: Cannot allocate memory" Date: Fri, 17 Dec 2010 10:06:05 +0000 Message-ID: References: <4D0B3A000200007800028A0C@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4D0B3A000200007800028A0C@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: anthony.perard@citrix.com, Charles Arnold , xen-devel@lists.xensource.com, Ian Jackson , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 17/12/2010 09:22, "Jan Beulich" 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