Re: [PATCH] virtio-balloon spec: provide a version of the "silent deflate" feature that works

On Fri, Sep 07, 2012 at 04:04:13PM +0200, Paolo Bonzini wrote:

Il 07/09/2012 14:44, Michael S. Tsirkin ha scritto:

quoted

quoted

Well, according to your reading of the spec.

In the spec I'm reading "Host must be told before pages from the balloon
are used".  Doesn't say anything about the guest.

No? How is host told then? By divine force?

For a simple madvise-based implementation such as the one in QEMU, the
host doesn't need to be told about anything (except periodic updating of
the "actual" field, or the statsq).

The guest doesn't need at all to use the deflateq in fact.

quoted

quoted

Now, indeed a very free interpretation is "Guest will tell host before
pages from the balloon are used".  It turns out that it's exactly what
guests have been doing, hence that's exactly what I'm proposing now:
rename the feature to VIRTIO_BALLOON_F_WILL_TELL_HOST.

Rename is fine.

Cool.

quoted

quoted

Yes, that part we agree on I think.  We disagree that (after the rename)
QEMU should start always proposing VIRTIO_BALLOON_F_WILL_TELL_HOST.

Not always. It must be off if compatibility with old qemu is disabled.

Yes, of course.

quoted

quoted

_Plus_ adding the new feature bit, which is needed to actually tell the

This part I do not get.  What is silent deflate, why is it useful
and what it has to do with what we are discussing here?

Silent deflate is deflating just by using the page, without using the
deflateq at all.  So it can be done even from GFP_ATOMIC context.

BTW I don't see a need to avoid deflateq.
Without MUST_TELL_HOST you can just deflate and then
bounce telling the host out to a thread.

But knowing that the guest will _not_ deflate silently also benefits the
host. This is the cause of unpinning ballooned pages and pinning them
again upon deflation. This allows cooperative memory overcommit even if
the guests' memory is pinned, similar to what Xen did before it
supported overcommit.  This is the second feature bit.

This is the MUST_TELL_HOST.

There are three cases:

* guest will never do silent deflation: current Linux driver.  Host may
do munlock/mlock dance.  Negotiates VIRTIO_BALLOON_F_WILL_TELL_HOST
only, features = VIRTIO_BALLOON_F_WILL_TELL_HOST.

* guest will always do silent deflation: current Windows driver.

Not exactly. It is not silent. It tells host
just after use.

Negotiates nothing, or if it cares it can negotiate
VIRTIO_BALLOON_F_SILENT_DEFLATE.  Host mustn't do munlock/mlock dance.

* guest may do silent deflation if available: combo of Linux driver +
Frank's driver.  Negotiates both features, looks at
VIRTIO_BALLOON_F_SILENT_DEFLATE host feature to decide how to behave:

  ** If PCI passthrough, the host will not negotiate
     VIRTIO_BALLOON_F_SILENT_DEFLATE.  The driver will behave as the
     current Linux driver, the host can do the munlock/mlock dance.

So this case is just existing interface. OK.

  ** If no PCI passthrough, the host will negotiate
     VIRTIO_BALLOON_F_SILENT_DEFLATE, and the driver can balloon more
     aggressively and not use the deflateq.

Paolo

This last trickery confuses me.  It just does not make sense to set both
SILENT and TELL: either you are silent or you tell.

What is the benefit of avoiding host notification?
It seems cleaner for the host to know the state.



-- 
MST