OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio] New virtio balloon...


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]