Re: [virtio] New virtio balloon...

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

Luiz Capitulino <lcapitulino@redhat.com> writes:
> On Wed, 05 Feb 2014 14:07:33 +1030
> Rusty Russell <rusty@au1.ibm.com> wrote:
>
>> 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.
>
> In this case, would it be better for the guests to swap instead of
> having the host to swap? If so, then yes I agree that maybe the guest
> should be able to say no.

s/guest/host/?  I think we're agreeing.

>> > 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?
>
> I honestly don't know whether it's a good idea for the host to take balloon
> decisions based on guest's stats. When I say host here I mean QEMU. IMO,
> the guest can do this faster and more accurately than QEMU.

I don't know either.  A call out to qemu is pretty fast, at least
compared with swapping a page.

> On another note, I'm getting a bit confused with this discussion. IMHO not
> all requirements are clear and I'm seeing you throwing code in... Maybe we
> should start by doing the spec instead? This might help us concentrate on
> providing the mechanisms only.

I thought we were closer to consensus than we are.  But providing a
strawman implementation highlighted our differences, so it's not a
complete waste :)

Cheers,
Rusty.