From: huangy81@chinatelecom.cn
To: qemu-devel <qemu-devel@nongnu.org>
Cc: "David Hildenbrand" <david@redhat.com>,
Hyman <huangy81@chinatelecom.cn>,
"Juan Quintela" <quintela@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Peter Xu" <peterx@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: [PATCH v1 0/3] support dirty restraint on vCPU
Date: Thu, 18 Nov 2021 14:07:19 +0800 [thread overview]
Message-ID: <cover.1637214721.git.huangy81@chinatelecom.cn> (raw)
From: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
this patchset introduce a mechanism to impose dirty restraint
on vCPU, aiming to keep the vCPU running in a certain dirtyrate
given by user. dirty restraint on vCPU maybe an alternative
method to implement convergence logic for live migration,
which could improve guest memory performance during migration
compared with traditional method in theory.
For the current live migration implementation, the convergence
logic throttles all vCPUs of the VM, which has some side effects.
-'read processes' on vCPU will be unnecessarily penalized
- throttle increase percentage step by step, which seems
struggling to find the optimal throttle percentage when
dirtyrate is high.
- hard to predict the remaining time of migration if the
throttling percentage reachs 99%
to a certain extent, the dirty restraint machnism can fix these
effects by throttling at vCPU granularity during migration.
the implementation is rather straightforward, we calculate
vCPU dirtyrate via the Dirty Ring mechanism periodically
as the commit 0e21bf246 "implement dirty-ring dirtyrate calculation"
does, for vCPU that be specified to impose dirty restraint,
we throttle it periodically as the auto-converge does, once after
throttling, we compare the quota dirtyrate with current dirtyrate,
if current dirtyrate is not under the quota, increase the throttling
percentage until current dirtyrate is under the quota.
this patchset is the basis of implmenting a new auto-converge method
for live migration, we introduce two qmp commands for impose/cancel
the dirty restraint on specified vCPU, so it also can be an independent
api to supply the upper app such as libvirt, which can use it to
implement the convergence logic during live migration, supplemented
with the qmp 'calc-dirty-rate' command or whatever.
we post this patchset for RFC and any corrections and suggetions about
the implementation, api, throttleing algorithm or whatever are very
appreciated!
Please review, thanks !
Best Regards !
Hyman Huang (3):
migration/dirtyrate: implement vCPU dirtyrate calculation periodically
cpu-throttle: implement vCPU throttle
cpus-common: implement dirty restraint on vCPU
cpus-common.c | 45 ++++++
include/exec/memory.h | 5 +-
include/hw/core/cpu.h | 7 +
include/sysemu/cpu-throttle.h | 21 +++
include/sysemu/dirtyrestraint.h | 22 +++
migration/dirtyrate.c | 125 +++++++++++++++++
migration/dirtyrate.h | 2 +
qapi/misc.json | 44 ++++++
softmmu/cpu-throttle.c | 304 ++++++++++++++++++++++++++++++++++++++++
softmmu/trace-events | 5 +
softmmu/vl.c | 1 +
11 files changed, 580 insertions(+), 1 deletion(-)
create mode 100644 include/sysemu/dirtyrestraint.h
--
1.8.3.1
next reply other threads:[~2021-11-18 6:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-18 6:07 huangy81 [this message]
2021-11-18 6:07 ` [PATCH v1 1/3] migration/dirtyrate: implement vCPU dirtyrate calculation periodically huangy81
2021-11-18 9:26 ` Juan Quintela
2021-11-18 6:07 ` [PATCH v1 2/3] cpu-throttle: implement vCPU throttle huangy81
2021-11-18 6:07 ` [PATCH v1 3/3] cpus-common: implement dirty restraint on vCPU 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.1637214721.git.huangy81@chinatelecom.cn \
--to=huangy81@chinatelecom.cn \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=richard.henderson@linaro.org \
/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).