From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andres Lagar-Cavilla" Subject: Re: [PATCH] RFC: initial libxl support for xenpaging Date: Fri, 17 Feb 2012 08:55:38 -0800 Message-ID: References: Reply-To: andres@lagarcavilla.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com Cc: olaf@aepfle.de, ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.org > Date: Fri, 17 Feb 2012 16:43:18 +0000 > From: Ian Campbell > To: Olaf Hering > Cc: "xen-devel@lists.xensource.com" > Subject: Re: [Xen-devel] [PATCH] RFC: initial libxl support for > xenpaging > Message-ID: <1329496998.3131.131.camel@zakaz.uk.xensource.com> > Content-Type: text/plain; charset="UTF-8" > > On Fri, 2012-02-17 at 16:03 +0000, Olaf Hering wrote: >> On Fri, Feb 17, Ian Campbell wrote: >> >> > That's exactly the sort of complexity we should not be exposing to the >> > end user! >> >> Of course not as is! >> Right now one has to understand two values, maxmem and the size of the >> memhog called "guest balloon driver". Paging adds a third one. > > Right, but that third one should not be "paging size" or anything like > that, just like they should not really have to understand what "a memhog > called "guest balloon driver"" is. Even today the thing we actually > expose is just called "memory" in the configuration. > > The user cares about three things: > 1. The maximum amount of memory a guest can use. > 2. The amount of memory which the guest thinks it has. > 3. The actual amount of memory the guest has > > The fact that these are implemented by some combination of paging and/or > ballooning is not really of interest to the user. They only need to be > aware that if #3 < #2 then there is a performance cost and that even if > #2==#3 a guest which tries to use more memory than that will be suffer a > performance penalty. > > My point is that the memory knobs should be exposed to the user of xl as > semantically meaningful options without the need to refer to "the paging > target" or "the balloon target" which is why there should not IMHO be > "xl commands to adjust just ballooning and/or paging". > May I suggest you call these things 'memory' and 'footprint'? Users can adjust the memory the guest thinks it has (#2 above), and the footprint the domain will actually occupy (#3). Then footprint can be adjusted by paging or something else. I don't want to begin to think about how PoD would jive there. It only seems to affect 'footprint' during bootup. Andres > Ian. >