Re: [virtio] New virtio balloon...

[Luiz Capitulino <lcapitulino@redhat.com>]

On Thu, 06 Feb 2014 12:12:21 +1030
Rusty Russell <rusty@au1.ibm.com> wrote:

> Daniel Kiper <daniel.kiper@oracle.com> writes:
> > On Wed, Feb 05, 2014 at 01:45:38PM +1030, Rusty Russell wrote:
> >> self-ballooning?  It seems like they'll just fight over target values
> >> if they both try to act.
> >
> > Sadly, yep. I know about that issue. Do you mean that we would like to avoid
> > such situation in new VIRTIO balloon driver? Any other reasons?
> 
> To step back a moment: I feel that you, Luiz and I are engaged in a
> search for enlightenment, and we are slowly making progress!
> 
> The specification needs to be cover how to implement both device and
> driver.  Simple enough to implement correctly, complex enough to be
> useful.
> 
> I see Luiz, with his self-ballooning patch (which was basically a "gimme
> more mem please!" from the guest)

Yes, and then the host tries to reclaim memory from all guests if it gets
into pressure. Guests with idle memory and freeable caches should answer
the call.

But to be honest, my solution is still incomplete. The idea behind my project
is that guest and host should balance each other some way, but my last RFC
has an artificial parameter where a guest which is under memory pressure will
ignore the host's call for memory for a fixed period of time. Another problem
with my RFC is that it reclaims freeable caches way too slowly.

> heading in the same direction that
> Xen's self-balloon ended up.
> 
> Does this mean that the current (legacy) virtio ballon is completely
> backwards, and that experience shows that the guest must drive?  Or does
> it really mean that there are cases for both, and the we need a balloon
> driver which does both?
> 
> If both, it needs to be specified what side wins.  A feature bit would
> be the classic method.
> 
> If we really don't know, we should leave the balloon device out of the
> standard entirely for v1.0 rather than rushing it (except to reserve id
> 13 for the future virtio balloon).

I don't know which one should drive. My last RFC tries to match the current
balloon design, but maybe having the host doing the inflate and the guest
doing the deflate might be an interesting idea.

I think we shouldn't rush. Actually, I'd very much appreciate if we discuss
automatic/self ballooning calmly on a different thread.

On the hand, what does it mean not having the balloon device for v1.0? Does
it mean that we wouldn't have a balloon driver in Linux? I'm asking this
because there are user-space solutions out there for automatic/self
ballooning (like MoM) and we have support for ballooning in other virt stack
components (like in libvirt). Those guys would break w/o a balloon device.