From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: QEMU bumping memory bug analysis Date: Tue, 9 Jun 2015 11:00:12 +0100 Message-ID: <5576B92C.9090300@eu.citrix.com> References: <20150605164354.GK29102@zion.uk.xensource.com> <1433530180.3342.17.camel@citrix.com> <1433765498.7108.480.camel@citrix.com> <5575A4C5.5070702@eu.citrix.com> <5575AE47.3020208@one.verizon.com> <5575B6D0.8010407@eu.citrix.com> <5575BD94.2010408@one.verizon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5575BD94.2010408@one.verizon.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Don Slutz , Stefano Stabellini , Ian Campbell Cc: Ian Jackson , Andrew Cooper , Wei Liu , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 06/08/2015 05:06 PM, Don Slutz wrote: > On 06/08/15 11:37, George Dunlap wrote: >>>> We already have the problem that the balloon driver at the moment >>>> doesn't actually know how big the guest RAM is, nor , but is being told >>>> to make a balloon exactly big enough to bring the total RAM down to a >>>> specific target. >>>> >>>> I think we do need to have some place in the middle that actually knows >>>> how much memory is actually needed for the different sub-systems, so it >>>> can calculate and set maxmem appropriately. libxl is the obvious place. >>> >>> Maybe. So you want libxl to know the detail of balloon overhead? How >>> about the different sizes of all possible Option ROMs in all QEMU >>> version? What about hvmloader usage of memory? >> >> I'm not sure what you mean by "balloon overhead", but if you mean "guest >> pages wasted keeping track of pages which have been ballooned out", then >> no, that's not what I mean. Neither libxl nor the balloon driver keep >> track of that at the moment. >> > > I was trying to refer to: > > NOTE: Because of the way ballooning works, the guest has to allocate > memory to keep track of maxmem pages, regardless of how much memory it > actually has available to it. A guest with maxmem=262144 and > memory=8096 will report significantly less memory available for use than > a system with maxmem=8096 memory=8096 due to the memory overhead of > having to track the unused pages. > > (from xl.cfg man page). Right -- that's what I guessed. As I said, at the moment the balloon driver is (in theory) given the target and asked to balloon down such that tot_pages that the guest uses would be equal to the tot_pages it would use if it were given that amount of memory. It's got nothing to do with what a user process sees from inside the guest (which is what this note is referring to). >> I think that qemu needs to tell libxl how much memory it is using for >> all of its needs -- including option ROMs. (See my example below.) For >> older qemus we can just make some assumptions like we always have. >> > > I am happy with this. Note: I think libxl could determine this number > now without QEMU changes. However it does depend on no other thread > changing a "staring" domain's memory while libxl is calculating this. > >> I do think it would make sense to have the hvmloader amount listed >> somewhere explicitly. I'm not sure how often hvmloader may need to >> change the amount it uses for itself. >> > > hvmloader does yet a different method. If > xc_domain_populate_physmap_exact() fails, it reduces guest RAM (if my > memory is correct). This makes me wonder if we could make qemu do the same thing. -George