Il 10/09/2012 08:47, Michael S. Tsirkin ha scritto: > On Mon, Sep 10, 2012 at 08:38:09AM +0200, Paolo Bonzini wrote: >> Il 10/09/2012 08:03, Michael S. Tsirkin ha scritto: >>> On Mon, Sep 10, 2012 at 07:50:13AM +0200, Paolo Bonzini wrote: >>>> Il 09/09/2012 00:22, Michael S. Tsirkin ha scritto: >>>>>> Almost. One is "the guest, if really needed, can tell the host of >>>>>> pages". If not negotiated, and the host does not support it, the host >>>>>> must break the guest (e.g. fail to offer any virtqueues). >>>>> >>>>> There is no way in spec to break the guest. >>>>> You can not fail to offer virtqueues. >>>> >>>> You can always return 0 for the first queue. >>> >>> I don't think guest drivers recover gracefully from this. >>> Do they? >> >> No, that's the point ("break the guest" is really "break the driver"). > > You can just stop VM then. No need for a side channel.
Keeping the VM running, just with no balloon driver is preferrable. >>>>>> The other is "the guest, though, would prefer not to do so". It is >>>>>> different because the guest can proceed in a fallback mode even if the >>>>>> host doesn't offer it. >>>>> >>>>> I think I get what your proposed SILENT means what I do not get >>>>> is the motivation. It looks like a premature optimization to me. >>>> >>>> The motivation is to let the driver choose between two behaviors: the >>>> current one where ballooning is only done on request, and a more >>>> aggressive one. >>> >>> Yes but why is being silent any good? Optimization? >>> Any data to show that it will help some workload? >> >> Idle guests can move cache pages to the balloon. You can overcommit >> more aggressively, because the host can madvise away a lot more memory. > > IMHO this feature needs more thought. E.g. how will this work with assignment? Revert to normal cooperative ballooning. > If we build something let's build it in a way that plays nicely > with other features. Yes, that's the point of SILENT. :) Paolo _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization