qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Chuang Xu <xuchuangxclwt@bytedance.com>
Cc: qemu-devel@nongnu.org, dgilbert@redhat.com, quintela@redhat.com,
	zhouyibo@bytedance.com, Paolo Bonzini <pbonzini@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [RFC PATCH] migration: reduce time of loading non-iterable vmstate
Date: Thu, 24 Nov 2022 11:40:34 -0500	[thread overview]
Message-ID: <Y3+egjXTvLEHDjuT@x1n> (raw)
In-Reply-To: <20221118083648.2399615-1-xuchuangxclwt@bytedance.com>

On Fri, Nov 18, 2022 at 04:36:48PM +0800, Chuang Xu wrote:
> The duration of loading non-iterable vmstate accounts for a significant
> portion of downtime (starting with the timestamp of source qemu stop and
> ending with the timestamp of target qemu start). Most of the time is spent
> committing memory region changes repeatedly.
> 
> This patch packs all the changes to memory region during the period of
> loading non-iterable vmstate in a single memory transaction. With the
> increase of devices, this patch will greatly improve the performance.
> 
> Here are the test results:
> test vm info:
> - 32 CPUs 128GB RAM
> - 8 16-queue vhost-net device
> - 16 4-queue vhost-user-blk device.
> 
> 	time of loading non-iterable vmstate
> before		about 210 ms
> after		about 40 ms
> 
> Signed-off-by: Chuang Xu <xuchuangxclwt@bytedance.com>

This is an interesting idea..  I think it means at least the address space
operations will all be messed up if happening during the precopy loading
progress, but I don't directly see its happening either.  For example, in
most post_load()s of vmsd I think the devices should just write directly to
its buffers, accessing MRs directly, even if they want DMAs or just update
fields to correct states.  Even so, I'm not super confident that holds
true, not to mention any other side effects (e.g., would we release bql
during precopy for any reason?).

Copy Paolo and PeterM for some extra eyes.

> ---
>  migration/migration.c | 1 +
>  migration/migration.h | 2 ++
>  migration/savevm.c    | 8 ++++++++
>  3 files changed, 11 insertions(+)
> 
> diff --git a/migration/migration.c b/migration/migration.c
> index e6f8bc2478..ed20704552 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -224,6 +224,7 @@ void migration_object_init(void)
>      qemu_sem_init(&current_incoming->postcopy_pause_sem_fast_load, 0);
>      qemu_mutex_init(&current_incoming->page_request_mutex);
>      current_incoming->page_requested = g_tree_new(page_request_addr_cmp);
> +    current_incoming->start_pack_mr_change = false;
>  
>      migration_object_check(current_migration, &error_fatal);
>  
> diff --git a/migration/migration.h b/migration/migration.h
> index 58b245b138..86597f5feb 100644
> --- a/migration/migration.h
> +++ b/migration/migration.h
> @@ -186,6 +186,8 @@ struct MigrationIncomingState {
>       * contains valid information.
>       */
>      QemuMutex page_request_mutex;
> +
> +    bool start_pack_mr_change;
>  };
>  
>  MigrationIncomingState *migration_incoming_get_current(void);
> diff --git a/migration/savevm.c b/migration/savevm.c
> index 48e85c052c..a073009a74 100644
> --- a/migration/savevm.c
> +++ b/migration/savevm.c
> @@ -2630,6 +2630,12 @@ retry:
>          switch (section_type) {
>          case QEMU_VM_SECTION_START:
>          case QEMU_VM_SECTION_FULL:
> +            /* call memory_region_transaction_begin() before loading non-iterable vmstate */
> +            if (section_type == QEMU_VM_SECTION_FULL && !mis->start_pack_mr_change) {
> +                memory_region_transaction_begin();
> +                mis->start_pack_mr_change = true;

This is slightly hacky to me.  Can we just wrap the begin/commit inside the
whole qemu_loadvm_state_main() call?

> +            }
> +
>              ret = qemu_loadvm_section_start_full(f, mis);
>              if (ret < 0) {
>                  goto out;
> @@ -2650,6 +2656,8 @@ retry:
>              }
>              break;
>          case QEMU_VM_EOF:
> +            /* call memory_region_transaction_commit() after loading non-iterable vmstate */
> +            memory_region_transaction_commit();
>              /* This is the end of migration */
>              goto out;
>          default:
> -- 
> 2.20.1
> 

-- 
Peter Xu



  reply	other threads:[~2022-11-24 16:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-18  8:36 [RFC PATCH] migration: reduce time of loading non-iterable vmstate Chuang Xu
2022-11-24 16:40 ` Peter Xu [this message]
2022-11-28  9:42   ` Chuang Xu
2022-11-28 17:41     ` Peter Xu
2022-12-05  6:56       ` Chuang Xu
2022-12-05 16:28         ` Peter Xu
2022-12-07 16:07           ` [External] " Chuang Xu
2022-12-07 22:08             ` Peter Xu
2022-12-08 14:39               ` Chuang Xu
2022-12-08 16:00                 ` Peter Xu
2022-12-09  7:32                   ` Chuang Xu
2022-12-09 14:33                   ` [External] " Chuang 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=Y3+egjXTvLEHDjuT@x1n \
    --to=peterx@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=xuchuangxclwt@bytedance.com \
    --cc=zhouyibo@bytedance.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).