qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: huangy81@chinatelecom.cn
To: qemu-devel <qemu-devel@nongnu.org>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	Eric Blake <eblake@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Hyman Huang <huangy81@chinatelecom.cn>
Subject: [RFC 0/6] migration: introduce dirtylimit capability
Date: Tue, 17 May 2022 14:35:00 +0800	[thread overview]
Message-ID: <cover.1652762652.git.huangy81@chinatelecom.cn> (raw)

From: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>

Abstract
========

This series added a new migration capability called "dirtylimit".  It can
be enabled when dirty ring is enabled, and it'll improve the vCPU performance
during the process of migration. It is based on the previous patchset:
https://lore.kernel.org/qemu-devel/cover.1648748793.git.huangy81@chinatelecom.cn/

As mentioned in patchset "support dirty restraint on vCPU", dirtylimit way of
migration can make the read-process not be penalized. This series wires up the
vcpu dirty limit and wrappers as dirtylimit capability of migration. I introduce
two parameters vcpu-dirtylimit-period and vcpu-dirtylimit to implement the setup 
of dirtylimit during live migration.

To validate the implementation, i tested a 32 vCPU vm live migration with such 
model:
Only dirty vcpu0, vcpu1 with heavy memory workoad and leave the rest vcpus
untouched, running unixbench on the vpcu8-vcpu15 by setup the cpu affinity as
the following command:
taskset -c 8-15 ./Run -i 2 -c 8 {unixbench test item}

The following are results:

host cpu: Intel(R) Xeon(R) Platinum 8378A
host interface speed: 1000Mb/s
  |---------------------+--------+------------+---------------|
  | UnixBench test item | Normal | Dirtylimit | Auto-converge |
  |---------------------+--------+------------+---------------|
  | dhry2reg            | 32800  | 32786      | 25292         |
  | whetstone-double    | 10326  | 10315      | 9847          |
  | pipe                | 15442  | 15271      | 14506         |
  | context1            | 7260   | 6235       | 4514          |
  | spawn               | 3663   | 3317       | 3249          |
  | syscall             | 4669   | 4667       | 3841          |
  |---------------------+--------+------------+---------------|
From the data above we can draw a conclusion that vcpus that do not dirty memory
in vm are almost unaffected during the dirtylimit migration, but the auto converge
way does. 

I also tested the total time of dirtylimit migration with variable dirty memory
size in vm.

senario 1:
host cpu: Intel(R) Xeon(R) Platinum 8378A
host interface speed: 1000Mb/s
  |-----------------------+----------------+-------------------|
  | dirty memory size(MB) | Dirtylimit(ms) | Auto-converge(ms) |
  |-----------------------+----------------+-------------------|
  | 60                    | 2014           | 2131              |
  | 70                    | 5381           | 12590             |
  | 90                    | 6037           | 33545             |
  | 110                   | 7660           | [*]               |
  |-----------------------+----------------+-------------------|
  [*]: This case means migration is not convergent. 

senario 2:
host cpu: Intel(R) Xeon(R) CPU E5-2650
host interface speed: 10000Mb/s
  |-----------------------+----------------+-------------------|
  | dirty memory size(MB) | Dirtylimit(ms) | Auto-converge(ms) |
  |-----------------------+----------------+-------------------|
  | 1600                  | 15842          | 27548             |
  | 2000                  | 19026          | 38447             |
  | 2400                  | 19897          | 46381             |
  | 2800                  | 22338          | 57149             |
  |-----------------------+----------------+-------------------|
Above data shows that dirtylimit way of migration can also reduce the total
time of migration and it achieves convergence more easily in some case.

Since the dependent patchset has not been merged yet, i post the series in the
the following link if anyone want to have a try, once the depenent patchset is
ready and merged, the dirtylimit can be availiable by patching series:
https://github.com/newfriday/qemu/tree/dirtylimit_cap_v1

This series is for RFC, comments and reviews about the API, code logic,
algo implementation or anything else are welcomed and appreciated

Please review, thanks !

Yong 

Hyman Huang (6):
  qapi/migration: Introduce vcpu-dirtylimit-period parameters
  qapi/migration: Introduce vcpu-dirtylimit parameters
  migration: Implement dirtylimit convergence algo
  migration: Introduce dirtylimit capability
  migration: Add dirtylimit data into migration info
  tests: Add migration dirtylimit capability test

 include/sysemu/dirtylimit.h  |  2 +
 migration/migration.c        | 48 ++++++++++++++++++++++++
 migration/migration.h        |  1 +
 migration/ram.c              | 53 +++++++++++++++++++-------
 migration/trace-events       |  1 +
 monitor/hmp-cmds.c           | 15 ++++++++
 qapi/migration.json          | 47 ++++++++++++++++++++---
 softmmu/dirtylimit.c         | 33 +++++++++++++++-
 tests/qtest/migration-test.c | 89 ++++++++++++++++++++++++++++++++++++++++++++
 9 files changed, 269 insertions(+), 20 deletions(-)

-- 
1.8.3.1



             reply	other threads:[~2022-05-17  6:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-17  6:35 huangy81 [this message]
2022-05-17  6:35 ` [RFC 1/6] qapi/migration: Introduce vcpu-dirtylimit-period parameters huangy81
2022-05-18 15:05   ` Eric Blake
2022-05-19  3:05     ` Hyman Huang
2022-05-17  6:35 ` [RFC 2/6] qapi/migration: Introduce vcpu-dirtylimit parameters huangy81
2022-05-18 15:06   ` Eric Blake
2022-05-17  6:35 ` [RFC 3/6] migration: Implement dirtylimit convergence algo huangy81
2022-05-17  6:35 ` [RFC 4/6] migration: Introduce dirtylimit capability huangy81
2022-05-18 15:20   ` Eric Blake
2022-05-17  6:35 ` [RFC 5/6] migration: Add dirtylimit data into migration info huangy81
2022-05-17  6:35 ` [RFC 6/6] tests: Add migration dirtylimit capability test huangy81

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=cover.1652762652.git.huangy81@chinatelecom.cn \
    --to=huangy81@chinatelecom.cn \
    --cc=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=thuth@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 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).