Re: [virtio] New virtio balloon...

[Rusty Russell <rusty@au1.ibm.com>]

Luiz Capitulino <lcapitulino@redhat.com> writes:
> On Tue, 4 Feb 2014 22:09:32 +0100
> Daniel Kiper <daniel.kiper@oracle.com> wrote:
>
>> > I chose to use stats + "need_mem" flag reporting for that method.  But
>> > if the host doesn't increase the target, the guest should not disobey.
>> 
>> So if I understand correctly we are going in such direction that only
>> host could control the target and guest may only gently ask for more
>> memory. Right? However, as I can see we do not have a mechanism to
>> directly reject guest requests for more memory.
>
> Honest question: do we need one? Or better, why would we want to reject
> a guest's request?
>
> With automatic ballooning for example, if the host is not able to supply
> a guest's need of memory, it would try to reclaim it from other guests.
> If this fails, the host goes through regular memory reclaim.

And if that fails?  What if there really isn't memory to give?  It might
really be under stress.

> Guests, on the other hand, need a way to refuse the host's request, at
> least temporarily, so that guests with enough free (or freeeable cached)
> memory have a chance to return memory to the host.

The guest doesn't know if the administrator has added a much more
important guest which needs all the memory, or if the memory savings
should be shared across multiple guests.

So if the host wants it to meet the target slowly, it should lower the
target slowly.  And monitor the stats to see how its progressing.

Note that the committed_as variable (which is used by HyperV and xen's
selfballoon apparently) *isn't* exposed through the stats, and it seems
it should be.  That seems to be the variable of choice?

Cheers,
Rusty.