From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: RE: Ballooning up Date: Tue, 14 Sep 2010 15:05:01 -0700 Message-ID: <4C8FF18D.4000900@goop.org> References: <4C85F973.2030007@goop.org> <54eebb3a-f539-43be-8134-a969a4f671c4@default 4C8EAB0E.7040407@goop.org> <2588d06f-8b7f-4cde-9a44-90906c66315f@default> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <2588d06f-8b7f-4cde-9a44-90906c66315f@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: Konrad Wilk , Xen-devel@lists.xensource.com, Daniel Kiper , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 09/14/2010 08:06 AM, Dan Magenheimer wrote: >> true, if you don't intend to balloon up, there's no point wasting >> memory on unused page structures. > I think this is the key. If dom0_mem is NOT specified, dom0 > launches with (essentially) all the physical memory of the > machine, page tables are allocated in dom0 to map all of physical > memory, and auto-ballooning is necessary to launch guests. > > If dom0_mem IS specified, it is often a much smaller number > than size of physical memory; why waste ~1.5% of physical memory > on page structures that will never be used? > > If someone wants to add an option to augment dom0_mem to allow > memory-up-ballooning of dom0 above dom0_mem (and can justify > a reason why some user might ever use this functionality), > that's fine. But let's not change the definition of the > dom0_mem option just because a bug fix happens to make it > possible. Technically (pedantically), the meaning of dom0_mem is unchanged - it sets the initial number of pages given to the domain, and is functionally identical to the normal "memory" parameter in a domU config file. The difference is that we're now paying attention to the E820 map, which is set by maxmem= in domU, but is the hardware/BIOS one in dom0. I'm not sure what I'm doing that's different to the xenolinux kernels; I guess they hack up the whole memory init path more aggressively. But the pvops behaviour is more or less the straightforward outcome of looking at the Xen-provided E820 and reserving the gaps between the actual page count and the memory described therein. J