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