From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: RE: Ballooning up Date: Tue, 14 Sep 2010 09:41:11 +0100 Message-ID: <4C8F51470200007800015EEA@vpn.id2.novell.com> References: <4C85F973.2030007@goop.org> <54eebb3a-f539-43be-8134-a969a4f671c4@default> <4C8EAB0E.7040407@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4C8EAB0E.7040407@goop.org> Content-Disposition: inline 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 , Dan Magenheimer Cc: Konrad Wilk , Xen-devel@lists.xensource.com, Daniel Kiper , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org >>> On 14.09.10 at 00:51, Jeremy Fitzhardinge wrote: > I guess there are three options: >=20 > 1. add a "xen_maxmem" (or something) kernel parameter to override > space specified in the E820 table Isn't that what the (native) "mem=3D" option is intended for? > 2. ignore E820 if its a privileged domain I think this upper limit specified by the machine E820 should be ignored here, and an option (as per 1.) should be available. > 3. only allow extra memory up to a certain ratio of the base memory > (8x? 16x? 32x?) Enforcing a sane upper limit of the ratio (we use 32x currently) seems like a reasonable thing to do in any case. Jan