Re: Ballooning up

[Jeremy Fitzhardinge <jeremy@goop.org>]

 On 09/15/2010 02:47 PM, Dan Magenheimer wrote:
> (rolling back to the original pre-drift topic)
>
>> From: Jeremy Fitzhardinge [mailto:jeremy@goop.org]
>> 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.

There are a number of pre-req patches to make it all work.  I'm in the
process of putting together a branch for upstreaming them.

    J