RE: [Xen-devel] Ballooning up

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

(rolling back to the original pre-drift topic)

> From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
> Subject: Re: [Xen-devel] Ballooning up
> 
>  On 09/07/2010 08:14 PM, Ian Campbell wrote:
> > On Tue, 2010-09-07 at 09:36 +0100, Jeremy Fitzhardinge wrote:
> >> I finally got around to implementing "ballooning up" in the pvops
> >> kernels.  Now if you start a domain with "memory=X maxmem=Y", the
> domain
> >> will start with X MB of memory, but you can use "x[ml] mem-set" to
> >> expand the domain up to Y.
> > Cool. What did the issue with plymouth and friends turn out to be?
> >
> 
> It was totalram_pages getting decremented when pages were being
> appended
> to the balloon, even though those pages were never counted.  So it got
> very low, and while it isn't actually used to account for how much free
> memory there is, some random pieces of code use something based on it
> to
> get a rough metric for free memory and block waiting for it to go up,
> or
> EAGAIN (or something).
> 
> It was a bit hard to directly observe because totalram_pages doesn't
> get
> displayed directly in /proc/meminfo, but removing the decrement showed
> that was the problem.

I went to try this out and it appears to me that the patch
that implements this is built on top of a fairly significant
sequence of E820-ish patches, none of which is upstream?  True?
Or is my rudimentary git knowledge misleading me?

This is important because the maxmem= functionality is primarily of
use in domU and it appears to be present in 2.6.18-based PV
kernels, but is not present in 2.6.32 (or later) pvops kernels,
so will appear to be a functionality regression.


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