From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [PATCH 00 of 24] xenpaging fixes for xen-unstable Date: Tue, 4 Oct 2011 17:05:45 +0200 Message-ID: <20111004150545.GA13277@aepfle.de> References: <1317721869.21903.110.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: <1317721869.21903.110.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Tue, Oct 04, Ian Campbell wrote: > totmem is unfortunately not all that descriptive to an end user of what > it does (which I think is a general problem we have with the memory > related options). > > Currently the xl config file options are: > memory = actual start of day RAM > maxmem = max ram guest could balloon to (?) > > How does POD fit in? Is it just maxmem-memory for HVM domains? (not > really relevant for this discussion, more for completeness). > > The associated command line options are: > mem-set (runtime equivalent of memory?) > mem-max (runtime equivalent of maxmem?) > > Hmm, I was hoping that enumerating the existing options would make the > name and semantics of the paging option magically pop into my head, I > was wrong :-( > > BTW tools/libxl/libxl_memory.txt should be patched by this series too, > once we figure out what to call things. > > The phrase "actual memory" is used in that document -- perhaps that is > suitable terminology for totmem? The naming of the various numbers is confusing, so far I could not come up with a better name than tot_pages. "actual target" is close to what xenpaging leaves for the guest, the amount of video ram has to be substracted. I think the code in libxl, xenstore and in my changes is not 100% consistent with the figure below. I have to wade through the individual members again and check if the math is correct in all places. Olaf /* === Domain memory breakdown: HVM guests ================================== + +----------+ + | | shadow | | | +----------+ | overhead | | extra | | | | external | | | +----------+ + | | | extra | | | | | internal | | | + +----------+ + | | footprint | | video | | | | | +----------+ + + + | | xen | | | | | guest OS | | | actual | maximum | | | guest | | real RAM | | | target | | | | | | | | build | | | | +----------+ + | | start + | | static | | paging | | | | | maximum | +----------+ | + + + | | | | | | | | | | balloon | | build | | | | maximum | | | | + +----------+ + extra internal = LIBXL_MAXMEM_CONSTANT extra external = LIBXL_HVM_EXTRA_MEMORY shadow = libxl_domain_build_info.shadow_memkb static maximum = libxl_domain_build_info.max_memkb video = libxl_domain_build_info.video_memkb build start = libxl_domain_build_info.target_memkb libxl_domain_setmaxmem -> xen maximum libxl_set_memory_target -> actual target build maximum = RAM as seen inside the virtual machine Increase/Decrease via memory hotplug of virtual hardware (?) xl mem-max (?) build start = RAM usable by the guest OS guest OS sees balloon driver as memory hog (?) Increase/Decrease via commands to the balloon driver xl mem-set real RAM = RAM allocated for the guest Increase/Decrease via commands to paging daemon xl mem-FOO guest = real RAM paging = virtual RAM / swap balloon = will become real or virtual RAM after mem-set command