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

["Charles Arnold" <carnold@xxxxxxxxxx>]

>>> On 1/6/2011 at 10:14 AM, in message <4D25C782.5B74.0091.0@xxxxxxxxxx>, 
>>> Charles
Arnold wrote: 
> >>> 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.
> 

Attached is the messages file with the printk output.

- 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;
>>      }
> 
>

Attachment: messages
Description: Binary data

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