[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [PATCH] linux/balloon: don't allow ballooningdown a domain below a reasonable limit
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |