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

["Dan Magenheimer" <dan.magenheimer@oracle.com>]

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@novell.com]
> Sent: Wednesday, April 30, 2008 12:29 AM
> To: dan.magenheimer@oracle.com
> Cc: Keir Fraser; xen-devel@lists.xensource.com; Ky Srinivasan;
> KurtGarloff
> Subject: RE: [Xen-devel] [PATCH] linux/balloon: don't allow
> ballooningdowna domain below a reasonable limit
> 
> 
> >>> "Dan Magenheimer" <dan.magenheimer@oracle.com> 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
> 
>