[lkml]   [2012]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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:
    > >> 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.


     \ /
      Last update: 2012-09-07 18:03    [W:0.032 / U:67.336 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site