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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
