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: Charles Arnold <carnold@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: Thu, 6 Jan 2011 16:50:53 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Stefano
Delivery-date: Thu, 06 Jan 2011 08:51:24 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D24453F02000091000691C5@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <C9302D00.D25D%keir@xxxxxxx> <alpine.DEB.2.00.1101051422360.2390@kaball-desktop> <4D24453F02000091000691C5@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
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,
        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