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: "Stefano Stabellini" <stefano.stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen 4.0.1 "xc_map_foreign_batch: mmap failed: Cannot allocate memory"
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 07 Jan 2011 12:37:10 +0000
Cc: Charles Arnold <CARNOLD@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 07 Jan 2011 04:38:00 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1101071115280.2390@kaball-desktop>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 07.01.11 at 12:18, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> On Fri, 7 Jan 2011, Jan Beulich wrote:
>> >>> On 06.01.11 at 21:49, Charles Arnold wrote:
>> > >>> On 1/6/2011 at 10:14 AM, in message <4D25C782.5B74.0091.0@xxxxxxxxxx>, 
> Charles Arnold wrote: 
>> > Attached is the messages file with the printk output.
>> Hmm, a failure due to may_expand_vm() is really odd. Something
>> must be explicitly setting a non-infinite RLIMIT_AS on qemu-dm (or
>> one of its parents), as the default is "infinite" (as reaching "infinity"
>> - being ~0UL - is simply impossible, and unduly large lengths should
>> be caught by get_unmapped_area() already).
>> /proc/<pid>/limits would at least tell us what the limit is.
> Knowing this would be very interesting.

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

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.

>> 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).


Xen-devel mailing list