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

[Michael S. Tsirkin]

On Fri, Sep 07, 2012 at 04:04:13PM +0200, Paolo Bonzini wrote:
> Il 07/09/2012 14:44, Michael S. Tsirkin ha scritto:
> >> 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.
> 
> >> 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.
> 
> >> 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.
> 
> >> _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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/