Re: [virtio] New virtio balloon...

[Luiz Capitulino <lcapitulino@redhat.com>]

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.

> > 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.

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.