Re: [Xen-devel] [Memory Accounting] was: Re: PVH dom0 creation fails - the system freezes

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 07/25/2018 02:56 PM, Andrew Cooper wrote:
> On 25/07/18 17:29, Juergen Gross wrote:
>> On 25/07/18 18:12, Roger Pau Monné wrote:
>>> On Wed, Jul 25, 2018 at 05:05:35PM +0300, bercarug@xxxxxxxxxx wrote:
>>>> On 07/25/2018 05:02 PM, Wei Liu wrote:
>>>>> On Wed, Jul 25, 2018 at 03:41:11PM +0200, Juergen Gross wrote:
>>>>>> On 25/07/18 15:35, Roger Pau Monné wrote:
>>>>>>>> What could be causing the available memory loss problem?
>>>>>>> That seems to be Linux aggressively ballooning out memory, you go from
>>>>>>> 7129M total memory to 246M. Are you creating a lot of domains?
>>>>>> This might be related to the tools thinking dom0 is a PV domain.
>>>>> Good point.
>>>>>
>>>>> In that case, xenstore-ls -fp would also be useful. The output should
>>>>> show the balloon target for Dom0.
>>>>>
>>>>> You can also try to set the autoballoon to off in /etc/xen/xl.cfg to see
>>>>> if it makes any difference.
>>>>>
>>>>> Wei.
>>>> Also tried setting autoballooning off, but it had no effect.
>>> This is a Linux/libxl issue that I'm not sure what's the best way to
>>> solve. Linux has the following 'workaround' in the balloon driver:
>>>
>>> err = xenbus_scanf(XBT_NIL, "memory", "static-max", "%llu",
>>>                &static_max);
>>> if (err != 1)
>>>     static_max = new_target;
>>> else
>>>     static_max >>= PAGE_SHIFT - 10;
>>> target_diff = xen_pv_domain() ? 0
>>>             : static_max - balloon_stats.target_pages;
>> Hmm, shouldn't PVH behave the same way as PV here? I don't think
>> there is memory missing for PVH, opposed to HVM's firmware memory.
>>
>> Adding Boris for a second opinion.

(Notwithstanding Andrews' rant below ;-))

I am trying to remember --- what memory were we trying not to online for
HVM here?


-boris


> /sigh
>
> <rant>
>
> Ballooning, and guest memory accounting is a known, growing, clustermess
> of swamps.  The ballooning protocol itself is sufficiently broken as to
> be useless outside of contrived scenarios, owing to the lack of any
> ability to nack the request and the guest not knowing or being able to
> work out how much RAM it actually has.
>
> The Xen/toolstack/qemu-{trad,upstream}/hvmloader guessathon contributes
> to lots of corner cases where things explode spectacularly on migration,
> such as having more than 4 network cards, or having vram != 64M, or
> generally anything involving PCI Passthrough.
>
> Can we take this hint that maybe its time to try fixing the problem
> properly rather than applying even more duct tape?  I'd like to remind
> people that there is a design which has been discussed at various
> conferences in the past, not not overly objected to.
>
> </rant>
>
> ~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel