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

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

OK, I think I am understanding it a bit better:
the max_pfn part is just adding in some "slop"
which is a fraction of total main memory which
is growing smaller (roughly logarithmically)
as memory grows larger.  I'm still not sure about
the magic values in MB2PAGES though... I'm guessing
these were gathered somehow experimentally?

With the "divide result of your algorithm by two",
I was able to get thirteen 512MB domains (idle
for now) running on a 2GB system.

I'm experimenting now with an algorithm which starts
with vm_committed_space* and adds back in a (for
now) fixed fraction of 1/32 of total physical
memory.

Dan

* Alas this is not exported so won't work in a module,
but it seems to be a pretty good estimator of active
virtual memory usage.

> -----Original Message-----
> From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx]
> Sent: Wednesday, April 30, 2008 10:04 AM
> To: 'Jan Beulich'
> Cc: 'Keir Fraser'; 'xen-devel@xxxxxxxxxxxxxxxxxxx'; 'Ky Srinivasan';
> 'KurtGarloff'
> Subject: RE: [Xen-devel] [PATCH] linux/balloon: don't allow
> ballooningdowna domain below a reasonable limit
> 
> 
> Hi Jan --
> 
> Thanks for the reply.  I see the comment now... it didn't
> find its way into the source.
> 
> I will definitely be working on tuning this estimate
> as I am working on maximizing the number of domains
> that can be run on a system and this is a constraint.
> As a quick-and-dirty test, I just divided the result
> of your algorithm (on a 512MB domain) by two and the
> maximally-ballooned kernel still ran fine (with
> 86528kB instead of 173056kB).
> 
> Could you explain the logic behind your current algorithm?
> I understand you are trying to estimate the additional
> kernel data structure space with the addition of the
> max_pfn computation but don't understand why this
> is a good estimator. I also am wondering how you chose
> the magic values for x in MB2PAGES(x).  And also if
> you have any tests/workloads you might have used to evaluate
> the algorithm.
> 
> Thanks,
> Dan
> 
> > -----Original Message-----
> > From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx]
> > Sent: Wednesday, April 30, 2008 12:29 AM
> > To: dan.magenheimer@xxxxxxxxxx
> > Cc: Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxx; Ky Srinivasan;
> > KurtGarloff
> > Subject: RE: [Xen-devel] [PATCH] linux/balloon: don't allow
> > ballooningdowna domain below a reasonable limit
> > 
> > 
> > >>> "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> 29.04.08 
> 20:35 >>>
> > >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).
> > 
> > Sure, this was (in different wording) also stated in the comment
> > that came with the patch. A more precise estimate would certainly
> > be welcome, but I'm afraid is going to come with a much higher
> > (complexity) price tag. Unless you have something simple and
> > obvious in mind that we simply didn't spot...
> > 
> > Jan
> > 
> >


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel