Messages in this thread | | | Date | Mon, 13 May 2013 18:35:13 +0300 | From | "Michael S. Tsirkin" <> | Subject | Re: [RFC 2/2] virtio_balloon: auto-ballooning support |
| |
On Mon, May 13, 2013 at 11:22:58AM -0400, Rik van Riel wrote: > On 05/13/2013 11:16 AM, Michael S. Tsirkin wrote: > > >However, there's a big question mark: host specifies > >inflate, guest says deflate, who wins? > > If we're dealing with a NUMA guest, they could both win :) > > The host could see reduced memory use of the guest in one > place, while the guest could see increased memory availability > in another place... > > I also suspect that having some "churn" could help sort out > exactly what the working set is. > > >At some point Google sent patches that gave guest > >complete control over the balloon. > >This has the advantage that management isn't involved. > > I believe the Google patches still included some way for the > host to initiate balloon inflation on the guest side, because > the guest internal state alone is not enough to see when the > host is under memory pressure. > > I discussed the project with the Google developers in question > a little over a year ago, but I do not remember whether their > pressure notification went through qemu, or directly from the > host kernel to the guest kernel...
So increasing the max number of pages in balloon indicates host memory pressure to the guest? Fair enough but I wonder whether there's a way to make it more explicit in the interface, somehow.
> >And at some level it seems to make sense: why set > >an upper limit on size of the balloon? > >The bigger it is, the better. > > Response time. > > If too much of a guest's memory has been removed, it can take > too long for the guest to react to user requests, be it over > the web or ssh or something else...
Absolutely. But it's a Guest issue. Host does not care. If Guest wants to shoot itself in the foot it has many other ways to do this.
> -- > All rights reversed
| |