This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Xen 4.0.1 "xc_map_foreign_batch: mmap failed: Cannot all

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] Xen 4.0.1 "xc_map_foreign_batch: mmap failed: Cannot allocate memory"
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Mon, 10 Jan 2011 11:11:55 +0000
Cc: Arnold <CARNOLD@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Charles, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Mon, 10 Jan 2011 03:11:49 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D271706020000780002AFB2@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D26EC59020000780002AF40@xxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1101071115280.2390@kaball-desktop> <4D271706020000780002AFB2@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Fri, 7 Jan 2011, Jan Beulich wrote:
> I just found that on SLE11 this gets set to 80% (admin controllable)
> of the sum of physical (not accounting for the balloon) and swap
> memory. That's (at least on large systems using a relatively low
> dom0_mem= value) likely awfully low for qemu-dm serving large
> guests.
> However, it's only rlim_cur that gets set this low by default, and
> hence it would seem reasonable to me to have qemu-dm bump it
> to whatever getrlimit() returns in rlimit_max.

It seems reasonable to me too.

> >> And certainly qemu-dm needs to be prepared to have a
> >> non-infinite address space limit set on it.
> >> 
> > 
> > Currently the number of buckets and the bucket size in the mapcache are
> > statically defined depending on x86_32/x86_64.
> > It shouldn't be difficult to make them dynamic depending on RLIMIT_AS.
> That still wouldn't help if RLIMIT_AS gets changed when it's already
> running. The only proper way to deal with the situation as a whole
> (including but not limited to rlim_max being relatively low) is to get
> proper error handling implemented, either causing guest I/O to be
> throttled when mmap() fails, or no longer used mappings cleared
> (if that isn't being done already).

I am not sure that handling RLIMIT_AS dynamic changes while
qemu is running is worth the effort; but for sure we have to deal with
RLIMIT_AS being lower than expect at qemu startup time.

Xen-devel mailing list