Re: [PATCH v2 2/2] virtio-balloon spec: reintroduce "silent deflation" feature

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, May 29, 2013 at 10:47:08AM +0200, Paolo Bonzini wrote:
> Il 29/05/2013 09:49, Michael S. Tsirkin ha scritto:
> > On Tue, May 28, 2013 at 07:40:18PM +0200, Paolo Bonzini wrote:
> >> The original idea of the VIRTIO_BALLOON_F_MUST_TELL_HOST feature was to
> >> let drivers skip usage of the deflate queue when leaking the balloon
> >> ("silent deflation").  Guests may benefit from silent deflate by
> >> aggressively inflating the balloon; they know that they will be able to
> >> use ballooned pages without issuing a (blocking) request to the device.
> >>
> >> The previous patch redefined the feature to ensure correctness of the
> >> operation when drivers do not correctly report deflation.  This patch
> >> adds back the optimization.
> >>
> >> The new feature bit is for the host to tell the drivers if silent
> >> deflation is actually supported.  The meaning of the feature bit is
> >> reversed compared to the original, because the original meaning was
> >> not safe against migration.
> >>
> >> For features to be safe against migration, they have to be defined as
> >> "this is true if the guest _can_ do X".  For such a "positive" feature,
> >> migration is possible if the destination supports it, or the source
> >> didn't set it:
> >>
> >>     dest support      source set          ok?
> >>           T                T              T
> >>           T                F              T
> >>           F                T              F
> >>           F                F              T
> >>
> >> Instead, the old feature was defined as "this is true if the guest
> >> _cannot_ do X".  For such a "negative" feature, migration is possible
> >> if the destination supports it, or the source sets it:
> >>
> >>     dest support      source set          ok?
> >>           T                T              T
> >>           T                F              F
> >>           F                T              T
> >>           F                F              T
> >>
> >> However, the negotiated features are supposed to be the AND of the
> >> device- and driver-supported features.  In the F/T case, the feature
> >> would be negotiated by the source as T, and become F when negotiated on
> >> the destination.
> >>
> >> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > 
> > Do you have any numbers showing how this new feature improves
> > performance?
> > We are able to batch quite a lot of pages in a single deflate
> > request - is the overhead measureable in practice?
> 
> It's not only about better times, but also about better algorithms.  I
> started writing this after seeing the Google fileballoon driver.  For
> that implementation, the deflateq cannot be used at all.
> 
> Paolo

It seems weak to claim the algorithm is better without trying it
out in practice.

I asked the fileballoon driver author whether
it can use TELL_HOST or if that will be too much overhead.
He said don't know.


And in particular, I think a feature bit is a bad fit for deciding how
page will be reclaimed.  Whether you will want a page back soon can
change over time depending on load etc.  So if we can't just tell host
first always, then I think we need to give guest control to do this per
inflate command.


-- 
MST