Re: [virtio] New virtio balloon...

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

On Mon, Feb 03, 2014 at 02:29:36PM +0100, Daniel Kiper wrote:
> On Sun, Feb 02, 2014 at 06:21:14PM +0200, Michael S. Tsirkin wrote:
> > On Fri, Jan 31, 2014 at 04:01:39PM +1030, Rusty Russell wrote:
> > > "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> [...]
> 
> > > > 	- what's the status of page returned from balloon?
> > > > 	  is it zeroed or can it have old data in there?
> > > > 	  I think in practice Linux will sometimes map in a zero page,
> > > > 	  so guest can save cycles and avoid zeroing it out.
> > > > 	  I think we should tell this to guest when returning
> > > > 	  pages.
> > >
> > > QEMU may not know, since the kernel may not tell it.
> >
> > Depends on what QEMU does.
> > I think kernel always gives us zero pages when we allocate
> > memory, they must be initialized otherwise it's an information leak.
> >
> >
> > >  We should assume
> > > nothing, and let the guest zero if it needs to.  Seems like a premuture
> > > optimization.
> >
> > Possibly.
> 
> I think that at this stage driver should not make any assumption on page
> contents returned from balloon. However, I think that it should be an
> option to clear (zero) pages put into balloon. Xen balloon driver has
> such build time option however I think that it should be runtime option
> on by default. If somebody would like to save some cycles then he/she
> could turn this feature off.
> 
> > > > 	- I am guessing EXTRA_MEM is for uses like the ones proposed by
> > > > 	  Frank Swiderski from google that inflate/deflate balloon
> > > >           whenever guest wants (look for "Add a page cache-backed balloon
> > > > 	  device driver").
> > > >
> > > >           this is useful but - we need to distinguish pages
> > > > 	  like this from regular inflate.
> > > > 	  it's not just counter and host needs a way to know
> > > > 	  that it's target is reached
> > >
> > > The driver needs to explicitly ask for pages in that region.
> >
> > OK so we'll have an extra flag for that?
> >
> >
> > > > 	- do we even want to allow guest not telling host when it wants
> > > > 	  to reuse the page?
> > > > 	  if yes, I think this should be per-page somehow: when balloon
> > > > 	  is inflated guest should tell host whether it
> > > > 	  expects to use this page.
> > >
> > > I decided against it.  Making that optional got us into a mess, so now
> > > it's compulsory.  That also fits better with the idea of a negative
> > > balloon.
> > >
> > > > So I think we should accomodate these uses, and so we want the following flags:
> > > >
> > > > 	- WEAK_TARGET (that's the EXTRA_MEM but I think done in a better way)
> > > >           flag that specifies pages do not count against target,
> > > > 	  can be taken out of balloon.
> > > > 	  EXTRA_MEM suggests there's an upper limit on balloon size
> > > > 	  but IMHO that's just extra work for host: host does not care
> > > > 	  I think, give it as much as you want.
> > > > 	  set by guest, used by host
> > >
> > > I think that Daniel really does want more memory than the guest starts
> > > with.  And I think he still wants to use the balloon to control it.
> > > Daniel?
> 
> Yep, I posted my comments to that stuff earlier.
> 
> > > > 	- TELL_HOST flag that specifies guest will tell host before using pages
> > > > 	  (that's VIRTIO_BALLOON_F_MUST_TELL_HOST
> > > > 	  at the moment, listed here for completeness)
> > > > 	  set by guest, used by host
> > >
> > > Dislike.
> > >
> > > > 	- ZEROED
> > > > 	  flag that specifies that page returned to guest
> > > > 	  is zeroed
> > > > 	  set by host, used by guest
> > >
> > > I think that's silly.  Under Linux the guest doesn't need to know it's
> > > zeroed or not, it just frees the page.
> >
> > Yes but it's possible that linux will try to zero page right
> > after free. It won't be too hard to set a flag that it's
> > zeroed when we free it.
> >
> >
> > > > Each of the flags can be just a feature flag, and then
> > > > if we wants a mix of them host can create multiple
> > > > balloon devices with differnet flags, and guest looks for best
> > > > balloon for its purposes.
> > > >
> > > > Alternatively flags can be set and reported per page.
> > > >
> > > >
> > > > A couple of other suggestions:
> > > >
> > > > - how to accomodate memory pressure in guest?
> > > >   Let's add a field telling host how hard do we
> > > >   want our memory back
> > >
> > > That's very hard to define across guests.  Should we be using stats for
> > > that instead?  In fact, should we allow gratuitous stats sending,
> > > instead of a simple NEED_MEM flag?
> 
> I think that it should be simple as possible. Guest just set new target and host
> fulfill request or not. Guest slow down requests from balloon if requests cannot
> be fulfilled some time. That is all.

Hmm that's exactly the reverse of what Rusty suggests.

> Guest has best knowledge how to calculate
> memory needs. You should remember that guests are not always Linux stuff.
> Host should know how to prioritize requests among guests. However, I think
> that it is not directly related to balloon device/driver design.
> 
> Daniel