This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] Ballooning up

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: RE: [Xen-devel] Ballooning up
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Wed, 15 Sep 2010 14:47:07 -0700 (PDT)
Cc: Xen-devel@xxxxxxxxxxxxxxxxxxx, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>, Vasiliy G Tolstov <v.tolstov@xxxxxxxxx>, Daniel Kiper <dkiper@xxxxxxxxxxxx>, Konrad Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Wed, 15 Sep 2010 14:49:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C863D6C.3050105@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4C85F973.2030007@xxxxxxxx> <1283854445.14311.91.camel@xxxxxxxxxxxxxxxxxxxxxx 4C863D6C.3050105@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
(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

<Prev in Thread] Current Thread [Next in Thread>