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

Re: [Xen-devel] 32bit-pv-VM 128G memory limited



Xen's allocation policy is to allocate larger addresses before smaller
addresses (although allocating from closer NUMA node may dominate this). So
memory over 128G should get allocated first, for guests that can use it. If
the NUMA allocation policy is getting in the way, and you want to reserve
say 64G of memory always to be allocated last, irrespective of NUMA policy,
try adding dma_bitsize=36 as a Xen boot parameter.

For 32-bit PV guests, Xen already maintains a maximum-address-size: see
implementation and use of domain_clamp_alloc_bitsize().

 -- Keir

On 03/11/2009 06:14, "James (song wei)" <jsong@xxxxxxxxxx> wrote:

> 
> Keir 
>  could you please say it in more detail?
> 
> Thanks,
> James 
> 
> Keir Fraser-3 wrote:
>> 
>> This should all already happen by default.
>> 
>>  -- Keir
>> 
>> On 02/11/2009 07:49, "James Song" <jsong@xxxxxxxxxx> wrote:
>> 
>>> Hi, 
>>>  
>>>  
>>>     Since 32-bit pv-domUs require memory below the 128G boundary (IIRC)
>>> but
>>> tools don't enforce this.  So we need a "memory pool" for 32bit pv-domUs.
>>> When starting a 32-bit domU, allocate memory from this pool.  If starting
>>> a
>>> 64-bit domUs or 32bit hvm dom (which don't suffer the 128G boundary
>>> limitation), allocate memory from above the boundary first, only
>>> allocating
>>> from the lower pool when needed.
>>>  
>>> Thanks,
>>> James (Song Wei)
>>>  
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>> 
>> 



_______________________________________________
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®.