From: "Wang, Wei W" <wei.w.wang@intel.com>
To: David Hildenbrand <david@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Cc: "peterx@redhat.com" <peterx@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"dgilbert@redhat.com" <dgilbert@redhat.com>,
"quintela@redhat.com" <quintela@redhat.com>
Subject: RE: [PATCH v1] migration: clear the memory region dirty bitmap when skipping free pages
Date: Wed, 14 Jul 2021 14:58:31 +0000 [thread overview]
Message-ID: <64973ae51976490b864ded3ff628058c@intel.com> (raw)
In-Reply-To: <25a2203f-fe82-41a6-ab40-2e4b5522fa14@redhat.com>
On Wednesday, July 14, 2021 6:30 PM, David Hildenbrand wrote:
>
> On 14.07.21 12:27, Michael S. Tsirkin wrote:
> > On Wed, Jul 14, 2021 at 03:51:04AM -0400, Wei Wang wrote:
> >> When skipping free pages, their corresponding dirty bits in the
> >> memory region dirty bitmap need to be cleared. Otherwise the skipped
> >> pages will be sent in the next round after the migration thread syncs
> >> dirty bits from the memory region dirty bitmap.
> >>
> >> migration_clear_memory_region_dirty_bitmap_range is put outside the
> >> bitmap_mutex, becasue
> >
> > because?
> >
> >> memory_region_clear_dirty_bitmap is possible to block on the kvm slot
> >> mutex (don't want holding bitmap_mutex while blocked on another
> >> mutex), and clear_bmap_test_and_clear uses atomic operation.
>
> How is that different from our existing caller?
>
> Please either clean everything up, completely avoiding the lock (separate
> patch), or move it under the lock.
>
> Or am I missing something important?
That seems ok to me and Peter to have it outside the lock. Not sure if Dave or Juan knows the reason why clear_bmap needs to be under the mutex given that it is atomic operation.
Best,
Wei
next prev parent reply other threads:[~2021-07-14 15:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-14 7:51 [PATCH v1] migration: clear the memory region dirty bitmap when skipping free pages Wei Wang
2021-07-14 10:27 ` Michael S. Tsirkin
2021-07-14 10:30 ` David Hildenbrand
2021-07-14 14:58 ` Wang, Wei W [this message]
2021-07-14 15:24 ` Peter Xu
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=64973ae51976490b864ded3ff628058c@intel.com \
--to=wei.w.wang@intel.com \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=mst@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.