Re: [Xen-devel] Whats effect of EXTRA_MEM_RATIO

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Sun, Jun 02, 2013 at 02:57:11AM +0530, Rushikesh Jadhav wrote:
> Hi guys,
> 
> Im fairly new to the Xen Development & trying to understand ballooning.

OK.
> 
> While compiling a DomU kernel I'm trying to understand the e820 memory map
> w.r.t Xen,
> 
> I have modified arch/x86/xen/setup.c  EXTRA_MEM_RATIO  to 1 and can see
> that the guest can not balloon up more than 2GB. Below is the memory map of
> DomU with max mem as 16GB.
> 
> for EXTRA_MEM_RATIO  = 1
> 
> BIOS-provided physical RAM map:
>  Xen: 0000000000000000 - 00000000000a0000 (usable)
>  Xen: 00000000000a0000 - 0000000000100000 (reserved)
>  Xen: 0000000000100000 - 0000000080000000 (usable)
>  Xen: 0000000080000000 - 0000000400000000 (unusable)
> NX (Execute Disable) protection: active
> DMI not present or invalid.
> e820 update range: 0000000000000000 - 0000000000010000 (usable) ==>
> (reserved)
> e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
> No AGP bridge found
> last_pfn = 0x80000 max_arch_pfn = 0x400000000
> initial memory mapped : 0 - 0436c000
> Base memory trampoline at [ffff88000009b000] 9b000 size 20480
> init_memory_mapping: 0000000000000000-0000000080000000
>  0000000000 - 0080000000 page 4k
> kernel direct mapping tables up to 80000000 @ bfd000-1000000
> xen: setting RW the range fd6000 - 1000000
> 
> 
> for EXTRA_MEM_RATIO  = 10 the map is like below and can balloon up to 16GB.
> 

Right, that is the default value.

> BIOS-provided physical RAM map:
>  Xen: 0000000000000000 - 00000000000a0000 (usable)
>  Xen: 00000000000a0000 - 0000000000100000 (reserved)
>  Xen: 0000000000100000 - 0000000400000000 (usable)
> NX (Execute Disable) protection: active
> DMI not present or invalid.
> e820 update range: 0000000000000000 - 0000000000010000 (usable) ==>
> (reserved)
> e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
> No AGP bridge found
> last_pfn = 0x400000 max_arch_pfn = 0x400000000
> last_pfn = 0x100000 max_arch_pfn = 0x400000000
> initial memory mapped : 0 - 0436c000
> Base memory trampoline at [ffff88000009b000] 9b000 size 20480
> init_memory_mapping: 0000000000000000-0000000100000000
>  0000000000 - 0100000000 page 4k
> kernel direct mapping tables up to 100000000 @ 7fb000-1000000
> xen: setting RW the range fd6000 - 1000000
> init_memory_mapping: 0000000100000000-0000000400000000
>  0100000000 - 0400000000 page 4k
> kernel direct mapping tables up to 400000000 @ 601ef000-62200000
> xen: setting RW the range 619fb000 - 62200000
> 
> 
> 
> Can someone please help me understand its behavior and importance ?

Here is the explanation from the code:

384         /*                                                                  
    
385          * Clamp the amount of extra memory to a EXTRA_MEM_RATIO            
    
386          * factor the base size.  On non-highmem systems, the base          
    
387          * size is the full initial memory allocation; on highmem it        
    
388          * is limited to the max size of lowmem, so that it doesn't         
    
389          * get completely filled.                                           
    
390          *                                                                  
    
391          * In principle there could be a problem in lowmem systems if       
    
392          * the initial memory is also very large with respect to            
    
393          * lowmem, but we won't try to deal with that here.                 
    
394          */                                                                 
    
395         extra_pages = min(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)), 
    
396                           extra_pages);                                     
    

I am unclear on what you are exactly want to learn? The hypercalls or how
the balloning happens? IF so I would recommend you work backwards - look
at the balloon driver itself, how it decreases/increases the memory, and what
data structures it uses to figure out how much memory it can use. Then you
can go back to the setup.c to get an idea on how the E820 is being created.


> 
> Thanks.

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel