From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Ballooning up Date: Wed, 15 Sep 2010 15:41:38 -0700 Message-ID: <4C914BA2.20803@goop.org> References: <4C85F973.2030007@goop.org> <1283854445.14311.91.camel@zakaz.uk.xensource.com 4C863D6C.3050105@goop.org> <33d40376-0b82-42d8-971f-706abb60a6a3@default> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <33d40376-0b82-42d8-971f-706abb60a6a3@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: Xen-devel@lists.xensource.com, Ian Campbell , Stefano Stabellini , Konrad Wilk , Vasiliy G Tolstov , Daniel Kiper List-Id: xen-devel@lists.xenproject.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