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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel