From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: RE: Ballooning up Date: Wed, 15 Sep 2010 14:47:07 -0700 (PDT) Message-ID: <33d40376-0b82-42d8-971f-706abb60a6a3@default> References: <4C85F973.2030007@goop.org> <1283854445.14311.91.camel@zakaz.uk.xensource.com 4C863D6C.3050105@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4C863D6C.3050105@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge , Ian Campbell Cc: Xen-devel@lists.xensource.com, Stefano Stabellini , Vasiliy G Tolstov , Daniel Kiper , Konrad Wilk List-Id: xen-devel@lists.xenproject.org (rolling back to the original pre-drift topic) > From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] > Subject: Re: [Xen-devel] Ballooning up >=20 > 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=3DX maxmem=3DY", 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? > > >=20 > 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). >=20 > 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=3D 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.