[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Wed, 5 Jan 2011, Charles Arnold wrote:
> No, just the usual mmap error.  See the attached logs.
> 
> As a reminder, the following conditions exist to duplicate the problem.
> Host: x86_64 sles11sp1.  Boot with dom0_mem=2048M, set 
> (enable-dom0-ballooning no) in xend-config.sxp
> Hypervisor: x86_64 Xen 4.0.1
> Guests: win2k3 (32bit) and win2k8r2 (64bit)
> The win2k8r2 guest uses robocopy to copy a 10 Gig file from the win2k3 guest. 
>  It copied about 23.2% before failing. 

(I should have read the subject more carefully)

xc_map_foreign_batch: mmap failed: Cannot allocate memory

That is an mmap error on the xch->fd file descriptor.
Considering that the privcmd mmap implementation sets the vma
VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP and always returns success
the ENOMEM must come from do_mmap.
It could be that sysctl_max_map_count has been reached but it is 65530
by default while the maximum number of buckets in the mapcache on 64
bits is only 10000.
Or the kernel could really be out of memory but in that case isn't a
little strange that we get the error from xc_map_foreign_batch?

I think we need to add more tracing in the dom0 kernel to figure out
what the problem is.
What dom0 kernel are you using?
Could you add some printk to the kernel source and try again?
A patch like the following should be enough.

---



diff --git a/mm/mmap.c b/mm/mmap.c
index b179abb..3f65277 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -991,16 +991,20 @@ unsigned long do_mmap_pgoff(struct file *file, unsigned 
long addr,
 
        /* Careful about overflows.. */
        len = PAGE_ALIGN(len);
-       if (!len)
+       if (!len) {
+               printk("DEBUG PAGE_ALIGN ENOMEM\n");
                return -ENOMEM;
+       }
 
        /* offset overflow? */
        if ((pgoff + (len >> PAGE_SHIFT)) < pgoff)
                return -EOVERFLOW;
 
        /* Too many mappings? */
-       if (mm->map_count > sysctl_max_map_count)
+       if (mm->map_count > sysctl_max_map_count) {
+               printk("DEBUG too many mappings ENOMEM\n");
                return -ENOMEM;
+       }
 
        /* Obtain the address to map to. we verify (or select) it and ensure
         * that it represents a valid section of the address space.
@@ -1231,14 +1235,18 @@ unsigned long mmap_region(struct file *file, unsigned 
long addr,
 munmap_back:
        vma = find_vma_prepare(mm, addr, &prev, &rb_link, &rb_parent);
        if (vma && vma->vm_start < addr + len) {
-               if (do_munmap(mm, addr, len))
+               if (do_munmap(mm, addr, len)) {
+                       printk("DEBUG find_vma_prepare ENOMEM\n");
                        return -ENOMEM;
+               }
                goto munmap_back;
        }
 
        /* Check against address space limit. */
-       if (!may_expand_vm(mm, len >> PAGE_SHIFT))
+       if (!may_expand_vm(mm, len >> PAGE_SHIFT)) {
+               printk("DEBUG may_expand_vm ENOMEM\n");
                return -ENOMEM;
+       }
 
        /*
         * Set 'VM_NORESERVE' if we should not account for the
@@ -1259,8 +1267,10 @@ munmap_back:
         */
        if (accountable_mapping(file, vm_flags)) {
                charged = len >> PAGE_SHIFT;
-               if (security_vm_enough_memory(charged))
+               if (security_vm_enough_memory(charged)) {
+                       printk("DEBUG accountable_mapping ENOMEM\n");
                        return -ENOMEM;
+               }
                vm_flags |= VM_ACCOUNT;
        }
 
@@ -1278,6 +1288,7 @@ munmap_back:
         */
        vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
        if (!vma) {
+               printk("DEBUG kmem_cache_zalloc ENOMEM\n");
                error = -ENOMEM;
                goto unacct_error;
        }

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.