All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Chuang Xu <xuchuangxclwt@bytedance.com>
Cc: qemu-devel@nongnu.org,  dgilbert@redhat.com,
	 pbonzini@redhat.com, peterx@redhat.com,  david@redhat.com,
	 philmd@linaro.org, zhouyibo@bytedance.com
Subject: Re: [RFC v5 3/3] migration: reduce time of loading non-iterable vmstate
Date: Thu, 02 Feb 2023 12:01:04 +0100	[thread overview]
Message-ID: <87mt5ws55b.fsf@secure.mitica> (raw)
In-Reply-To: <20230117115511.3215273-4-xuchuangxclwt@bytedance.com> (Chuang Xu's message of "Tue, 17 Jan 2023 19:55:11 +0800")

Chuang Xu <xuchuangxclwt@bytedance.com> 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 test1 results:
> test info:
> - Host
>   - Intel(R) Xeon(R) Platinum 8260 CPU
>   - NVIDIA Mellanox ConnectX-5
> - VM
>   - 32 CPUs 128GB RAM VM
>   - 8 16-queue vhost-net device
>   - 16 4-queue vhost-user-blk device.
>
> 	time of loading non-iterable vmstate     downtime
> before		about 150 ms			  740+ ms
> after		about 30 ms			  630+ ms
>
> In test2, we keep the number of the device the same as test1, reduce the
> number of queues per device:
>
> Here are the test2 results:
> test info:
> - Host
>   - Intel(R) Xeon(R) Platinum 8260 CPU
>   - NVIDIA Mellanox ConnectX-5
> - VM
>   - 32 CPUs 128GB RAM VM
>   - 8 1-queue vhost-net device
>   - 16 1-queue vhost-user-blk device.
>
> 	time of loading non-iterable vmstate     downtime
> before		about 90 ms			 about 250 ms
>
> after		about 25 ms			 about 160 ms
>
> In test3, we keep the number of queues per device the same as test1, reduce
> the number of devices:
>
> Here are the test3 results:
> test info:
> - Host
>   - Intel(R) Xeon(R) Platinum 8260 CPU
>   - NVIDIA Mellanox ConnectX-5
> - VM
>   - 32 CPUs 128GB RAM VM
>   - 1 16-queue vhost-net device
>   - 1 4-queue vhost-user-blk device.
>
> 	time of loading non-iterable vmstate     downtime
> before		about 20 ms			 about 70 ms
> after		about 11 ms			 about 60 ms
>
> As we can see from the test results above, both the number of queues and
> the number of devices have a great impact on the time of loading non-iterable
> vmstate. The growth of the number of devices and queues will lead to more
> mr commits, and the time consumption caused by the flatview reconstruction
> will also increase.
>
> Signed-off-by: Chuang Xu <xuchuangxclwt@bytedance.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>

And BTW, nice load times improvements.



  reply	other threads:[~2023-02-02 11:01 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-17 11:55 [RFC v5 0/3] migration: reduce time of loading non-iterable vmstate Chuang Xu
2023-01-17 11:55 ` [RFC v5 1/3] rcu: introduce rcu_read_is_locked() Chuang Xu
2023-02-02 10:59   ` Juan Quintela
2023-02-14  7:57     ` Chuang Xu
2023-01-17 11:55 ` [RFC v5 2/3] memory: add depth assert in address_space_to_flatview Chuang Xu
2023-02-08 19:31   ` Juan Quintela
2023-01-17 11:55 ` [RFC v5 3/3] migration: reduce time of loading non-iterable vmstate Chuang Xu
2023-02-02 11:01   ` Juan Quintela [this message]
2023-01-17 15:41 ` [RFC v5 0/3] " Peter Xu
2023-02-02 11:07 ` Juan Quintela
2023-02-15 17:00 ` Juan Quintela
2023-02-15 17:06 ` Claudio Fontana
2023-02-15 19:10 ` Juan Quintela
2023-02-16 15:41   ` Chuang Xu
     [not found]   ` <a555b989-27be-006e-0d00-9f1688c5be4e@bytedance.com>
2023-02-17  8:11     ` Chuang Xu
2023-02-17 15:52       ` Peter Xu
2023-02-20 13:36         ` Chuang Xu
2023-02-21  3:38         ` Chuang Xu
2023-02-21  8:57           ` Chuang Xu
2023-02-21 20:36             ` Peter Xu
2023-02-22  6:27               ` Chuang Xu
2023-02-22 15:57                 ` Peter Xu
2023-02-23  3:28                   ` Chuang Xu
2023-02-25 15:32                     ` Peter Xu
2023-02-27 13:19                       ` Chuang Xu
2023-02-27 20:56                         ` Peter Xu
2023-02-20  9:53   ` Chuang Xu
2023-02-20 12:07     ` Juan Quintela

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=87mt5ws55b.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --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 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.