Re: [Xen-devel] QEMU bumping memory bug analysis

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel