Re: [virtio] New virtio balloon...

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Feb 06, 2014 at 08:44:22AM -0500, Luiz Capitulino wrote:
> 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.


It merely means people will have to use old balloon driver,
in particular balloon would have to be a PCI device (not PCI express).