RE: [Xen-devel] [PATCH] linux/balloon: don't allow ballooningdown a domain below a reasonable limit

["Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>]

I made some actual measurements of the results of this algorithm
(on a RHEL5u1-32bit guest).

memory= Minimum
128              75776kB
256             108544kB
512             173056kB
1024            238592kB

This corresponds to expected values in the source comment
However, I wonder if the algorithm is probably too
conservative for large(r) memory domains.  With
a light load (i.e. continuously compiling Xen),
memory utilization rarely exceeds 72MB, regardless
of the max memory (at least in the above tested values).

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Jan Beulich
> Sent: Monday, April 07, 2008 1:10 AM
> To: Keir Fraser
> Cc: Ky Srinivasan; xen-devel@xxxxxxxxxxxxxxxxxxx; Kurt Garloff
> Subject: Re: [Xen-devel] [PATCH] linux/balloon: don't allow
> ballooningdown a domain below a reasonable limit
> 
> 
> >>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 05.04.08 23:39 >>>
> >On 4/4/08 16:07, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
> >
> >> +#ifndef CONFIG_XEN
> >> +#define max_pfn totalram_pages
> >> +#endif
> >
> >This is silly. We modify totalram_pages as we balloon up and 
> down, so this
> >really isn't very max_pfn-like after ballooning gets under way.
> 
> Indeed. It's been a very long time since I had to last touch 
> this patch, so
> I can only assume that originally was meant to address a 
> build problem,
> and then got forgotten about.
> 
> >So I've applied the patch but I made it a no-op if 
> !defined(CONFIG_XEN),
> >until/unless someone comes up with a better alternative to 
> totalram_pages.
> >Possibly just latching totalram_pages when we install the 
> balloon driver
> >would be sufficient?
> 
> That would be one option, though not exactly representing what is
> intended here - the minimum memory requirement depends (at least for
> FLATMEM) much more on the size of the 'struct page' array than on the
> part of the array that's actually valid memory.
> Since max_mapnr doesn't get initialized for x86-64 and end_pfn is no
> longer being exported in 2.6.25, num_physpages would seem to be
> the only other alternative.
> 
> Jan
> 
> 
> _______________________________________________
> 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