Thank Keir very much for detailed explaining.
>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 2009-11-3 15:48 >>>
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>>
>>
