From: "Michael S. Tsirkin" <mst@redhat.com>
To: Wei Wang <wei.w.wang@intel.com>
Cc: qemu-devel@nongnu.org, virtio-dev@lists.oasis-open.org,
quintela@redhat.com, dgilbert@redhat.com, pbonzini@redhat.com,
liliang.opensource@gmail.com, yang.zhang.wz@gmail.com,
quan.xu0@gmail.com, nilal@redhat.com, riel@redhat.com
Subject: [virtio-dev] Re: [PATCH v3 2/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
Date: Tue, 6 Mar 2018 04:38:08 +0200 [thread overview]
Message-ID: <20180306042253-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <5A9DF4E9.3090706@intel.com>
On Tue, Mar 06, 2018 at 09:54:49AM +0800, Wei Wang wrote:
> On 03/05/2018 10:09 PM, Michael S. Tsirkin wrote:
> > On Mon, Mar 05, 2018 at 11:36:15AM +0800, Wei Wang wrote:
> > > On 03/03/2018 02:37 AM, Michael S. Tsirkin wrote:
> > > > On Fri, Mar 02, 2018 at 04:47:29PM +0800, Wei Wang wrote:
> > > > > diff --git a/include/sysemu/balloon.h b/include/sysemu/balloon.h
> > > > > index af49e19..16a2aae 100644
> > > > > --- a/include/sysemu/balloon.h
> > > > > +++ b/include/sysemu/balloon.h
> > > > ...
> > > >
> > > > > +typedef void (QEMUBalloonFreePageStart)(void *opaque);
> > > > > +typedef void (QEMUBalloonFreePageStop)(void *opaque);
> > > > So I think the rule is that no bitmap sync must happen
> > > > between these two, otherwise a hint might arrive and
> > > > override the sync output.
> > > >
> > > > Should be documented I think.
> > > >
> > > Yes, agree.
> > Ideally we'd also detect violations and trigger an assert.
>
> How about just invoking
>
> if (rs->free_page_support)
> balloon_free_page_stop();
>
> at the beginning of migration_bitmap_sync()? (balloon_free_page_stop will
> just return if the optimization has stopped.)
>
> In this way, we can always have the guarantee that "no bitmap sync must
> happen between these two"
Why not. And in fact you can do balloon_free_page_start at the
end of sync.
>
> >
> > > How about adding the following new balloon API explanation to
> > > this patch's commit:
> > >
> > > - balloon_free_page_start: Callers call this API to obtain guest free
> > > page hints, and clear the related bits from the migration dirty
> > > bitmap.
> > > The whole process is implemented in a new thread independent of the
> > > migration thread. Free page hints imply the part of guest memory is
> > > likely to be free without a guarantee. That is, the reported free
> > > pages
> > > may not be free any more when QEMU receives them, so callers are
> > > responsible for detecting those pages that are not free pages after
> > > the
> > > bits are cleared from the dirty bitmap. To ensure the above, this API
> > > should be used when the migration dirty logging mechanism (e.g.
> > > guest memory write-protection) has started.
> > >
> > > - balloon_free_page_stop: Callers call this API to stop the guest from
> > > reporting free page hints. Bits from the dirty bitmap are safe to
> > > be cleared on condition that the dirty logging mechanism is recording
> > > pages that the guest has written to. To avoid the case that clearing
> > > bits of free page hints overrides the dirty bits offered by the dirty
> > > logging mechanism, this API is suggested to be called before QEMU
> > > synchronizes the dirty logging bitmap.
> > >
> > > - balloon_free_page_support: This API is called to check whether the
> > > balloon device supports the guest free page reporting feature. The
> > > balloon_free_page_start and balloon_free_page_stop APIs should be used
> > > only when this API returns true.
> > >
> > >
> > > Best,
> > > Wei
> > I find this more confusing than explaining.
> >
> > Let me try
> >
> > balloon_free_page_start - start guest free page hint reporting.
> > Note: balloon will report pages which were free at the time
> > of this call. As the reporting happens asynchronously,
> > we rely on dirty logging to be started before this call is made.
> >
> > The dirty logging bitmap must be synchronized before this call
> > and then after balloon_free_page_stop.
>
> I think it would be better to remove the above one sentence.
> I agree "No dirty bitmap synchronizations are allowed between
> balloon_free_page_start and balloon_free_page_stop", but "The dirty logging
> bitmap MUST be synchronized before balloon_free_page_start" seems confusing,
> for example the bulk stage doesn't have to start with a bitmap sync.
OK I guess "dirty logging must be enabled" would be better.
And with above we can say hinting must be disabled
before logging bitmap is synchronized.
>
> >
> > balloon_free_page_stop: stop the guest reporting
> > of free pages. dirty logging bitmap can be synchronized
> > after this point.
> >
> > No bitmap synchronizations are allowed between these two points.
> >
>
> Best,
> Wei
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2018-03-06 2:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-02 8:47 [virtio-dev] [PATCH v3 0/3] virtio-balloon: free page hint reporting support Wei Wang
2018-03-02 8:47 ` [virtio-dev] [PATCH v3 1/3] migration: API to clear bits of guest free pages from the dirty bitmap Wei Wang
[not found] ` <20180307122348.GC3089@work-vm>
2018-03-07 12:57 ` [virtio-dev] " Wei Wang
2018-03-02 8:47 ` [virtio-dev] [PATCH v3 2/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT Wei Wang
2018-03-02 18:27 ` [virtio-dev] " Michael S. Tsirkin
2018-03-02 18:37 ` Michael S. Tsirkin
2018-03-05 3:36 ` Wei Wang
2018-03-05 14:09 ` Michael S. Tsirkin
2018-03-06 1:54 ` Wei Wang
2018-03-06 2:38 ` Michael S. Tsirkin [this message]
2018-03-07 13:09 ` Wei Wang
2018-03-02 8:47 ` [virtio-dev] [PATCH v3 3/3] migration: use the free page hint feature from balloon Wei Wang
[not found] ` <20180307123209.GD3089@work-vm>
2018-03-07 12:57 ` [virtio-dev] " Wei Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180306042253-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=dgilbert@redhat.com \
--cc=liliang.opensource@gmail.com \
--cc=nilal@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quan.xu0@gmail.com \
--cc=quintela@redhat.com \
--cc=riel@redhat.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=wei.w.wang@intel.com \
--cc=yang.zhang.wz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox