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