[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 1/6/2011 at 09:50 AM, in message <alpine.DEB.2.00.1101051748120.2390@kaball-desktop>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote: > 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? uname -a Linux xen86 2.6.32.24-0.2-xen #1 SMP 2010-10-29 16:39:49 +0200 x86_64 x86_64 x86_64 GNU/Linux This is sles11sp1. > Could you add some printk to the kernel source and try again? > A patch like the following should be enough. Yes, I'll report back after building and testing. Thanks, - Charles > > --- > > > > 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |