[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio] New virtio balloon...
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).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]