From: Peter Xu <peterx@redhat.com>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
Christian Schoenebeck <qemu_oss@crudebyte.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
peterx@redhat.com
Subject: [PATCH 2/2] migration: Postpone the kick of the fault thread after recover
Date: Mon, 2 Nov 2020 10:30:10 -0500 [thread overview]
Message-ID: <20201102153010.11979-3-peterx@redhat.com> (raw)
In-Reply-To: <20201102153010.11979-1-peterx@redhat.com>
The new migrate_send_rp_req_pages_pending() call should greatly improve
destination responsiveness because it will resync faulted address after
postcopy recovery. However it is also the 1st place to initiate the page
request from the main thread.
One thing is overlooked on that migrate_send_rp_message_req_pages() is not
designed to be thread-safe. So if we wake the fault thread before syncing all
the faulted pages in the main thread, it means they can race.
Postpone the wake up operation after the sync of faulted addresses.
Fixes: 0c26781c09 ("migration: Sync requested pages after postcopy recovery")
Tested-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
---
migration/savevm.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/migration/savevm.c b/migration/savevm.c
index e8834991ec..5f937a2762 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -2069,12 +2069,9 @@ static int loadvm_postcopy_handle_resume(MigrationIncomingState *mis)
/*
* This means source VM is ready to resume the postcopy migration.
- * It's time to switch state and release the fault thread to
- * continue service page faults.
*/
migrate_set_state(&mis->state, MIGRATION_STATUS_POSTCOPY_RECOVER,
MIGRATION_STATUS_POSTCOPY_ACTIVE);
- qemu_sem_post(&mis->postcopy_pause_sem_fault);
trace_loadvm_postcopy_handle_resume();
@@ -2095,6 +2092,14 @@ static int loadvm_postcopy_handle_resume(MigrationIncomingState *mis)
*/
migrate_send_rp_req_pages_pending(mis);
+ /*
+ * It's time to switch state and release the fault thread to continue
+ * service page faults. Note that this should be explicitly after the
+ * above call to migrate_send_rp_req_pages_pending(). In short:
+ * migrate_send_rp_message_req_pages() is not thread safe, yet.
+ */
+ qemu_sem_post(&mis->postcopy_pause_sem_fault);
+
return 0;
}
--
2.26.2
next prev parent reply other threads:[~2020-11-02 15:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-02 15:30 [PATCH 0/2] migration: Two extra fixes Peter Xu
2020-11-02 15:30 ` [PATCH 1/2] migration: Unify reset of last_rb on destination node when recover Peter Xu
2020-11-02 18:23 ` Dr. David Alan Gilbert
2020-11-02 15:30 ` Peter Xu [this message]
2020-11-02 18:24 ` [PATCH 2/2] migration: Postpone the kick of the fault thread after recover Dr. David Alan Gilbert
2020-11-02 18:26 ` [PATCH 0/2] migration: Two extra fixes Dr. David Alan Gilbert
2020-11-02 18:26 ` Dr. David Alan Gilbert
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=20201102153010.11979-3-peterx@redhat.com \
--to=peterx@redhat.com \
--cc=dgilbert@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.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;
as well as URLs for NNTP newsgroup(s).