From: Juan Quintela <quintela@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Markus Armbruster" <armbru@redhat.com>,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Juan Quintela" <quintela@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
libvir-list@redhat.com, "Peter Xu" <peterx@redhat.com>,
qemu-block@nongnu.org, "Eric Blake" <eblake@redhat.com>,
"Fam Zheng" <fam@euphon.net>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Leonardo Bras" <leobras@redhat.com>
Subject: [PATCH v2 1/5] migration: Use proper indentation for migration.json
Date: Thu, 22 Jun 2023 21:50:15 +0200 [thread overview]
Message-ID: <20230622195019.4396-2-quintela@redhat.com> (raw)
In-Reply-To: <20230622195019.4396-1-quintela@redhat.com>
We broke it with dirtyrate limit patches.
Signed-off-by: Juan Quintela <quintela@redhat.com>
---
qapi/migration.json | 67 ++++++++++++++++++++++-----------------------
1 file changed, 33 insertions(+), 34 deletions(-)
diff --git a/qapi/migration.json b/qapi/migration.json
index 6ff39157ba..ad8cc57071 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -258,17 +258,17 @@
# blocked. Present and non-empty when migration is blocked.
# (since 6.0)
#
-# @dirty-limit-throttle-time-per-round: Maximum throttle time (in microseconds) of virtual
-# CPUs each dirty ring full round, which shows how
-# MigrationCapability dirty-limit affects the guest
-# during live migration. (since 8.1)
+# @dirty-limit-throttle-time-per-round: Maximum throttle time (in
+# microseconds) of virtual CPUs each dirty ring full round, which
+# shows how MigrationCapability dirty-limit affects the guest
+# during live migration. (since 8.1)
#
-# @dirty-limit-ring-full-time: Estimated average dirty ring full time (in microseconds)
-# each dirty ring full round, note that the value equals
-# dirty ring memory size divided by average dirty page rate
-# of virtual CPU, which can be used to observe the average
-# memory load of virtual CPU indirectly. Note that zero
-# means guest doesn't dirty memory (since 8.1)
+# @dirty-limit-ring-full-time: Estimated average dirty ring full time
+# (in microseconds) each dirty ring full round, note that the
+# value equals dirty ring memory size divided by average dirty
+# page rate of virtual CPU, which can be used to observe the
+# average memory load of virtual CPU indirectly. Note that zero
+# means guest doesn't dirty memory (since 8.1)
#
# Since: 0.14
##
@@ -510,14 +510,13 @@
# (since 7.1)
#
# @dirty-limit: If enabled, migration will use the dirty-limit algo to
-# throttle down guest instead of auto-converge algo.
-# Throttle algo only works when vCPU's dirtyrate greater
-# than 'vcpu-dirty-limit', read processes in guest os
-# aren't penalized any more, so this algo can improve
-# performance of vCPU during live migration. This is an
-# optional performance feature and should not affect the
-# correctness of the existing auto-converge algo.
-# (since 8.1)
+# throttle down guest instead of auto-converge algo. Throttle
+# algo only works when vCPU's dirtyrate greater than
+# 'vcpu-dirty-limit', read processes in guest os aren't penalized
+# any more, so this algo can improve performance of vCPU during
+# live migration. This is an optional performance feature and
+# should not affect the correctness of the existing auto-converge
+# algo. (since 8.1)
#
# Features:
#
@@ -811,17 +810,17 @@
# Nodes are mapped to their block device name if there is one, and
# to their node name otherwise. (Since 5.2)
#
-# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty limit during
-# live migration. Should be in the range 1 to 1000ms,
-# defaults to 1000ms. (Since 8.1)
+# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty
+# limit during live migration. Should be in the range 1 to 1000ms,
+# defaults to 1000ms. (Since 8.1)
#
# @vcpu-dirty-limit: Dirtyrate limit (MB/s) during live migration.
-# Defaults to 1. (Since 8.1)
+# Defaults to 1. (Since 8.1)
#
# Features:
#
# @unstable: Members @x-checkpoint-delay and @x-vcpu-dirty-limit-period
-# are experimental.
+# are experimental.
#
# Since: 2.4
##
@@ -977,17 +976,17 @@
# Nodes are mapped to their block device name if there is one, and
# to their node name otherwise. (Since 5.2)
#
-# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty limit during
-# live migration. Should be in the range 1 to 1000ms,
-# defaults to 1000ms. (Since 8.1)
+# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty
+# limit during live migration. Should be in the range 1 to 1000ms,
+# defaults to 1000ms. (Since 8.1)
#
# @vcpu-dirty-limit: Dirtyrate limit (MB/s) during live migration.
-# Defaults to 1. (Since 8.1)
+# Defaults to 1. (Since 8.1)
#
# Features:
#
# @unstable: Members @x-checkpoint-delay and @x-vcpu-dirty-limit-period
-# are experimental.
+# are experimental.
#
# TODO: either fuse back into MigrationParameters, or make
# MigrationParameters members mandatory
@@ -1180,17 +1179,17 @@
# Nodes are mapped to their block device name if there is one, and
# to their node name otherwise. (Since 5.2)
#
-# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty limit during
-# live migration. Should be in the range 1 to 1000ms,
-# defaults to 1000ms. (Since 8.1)
+# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty
+# limit during live migration. Should be in the range 1 to 1000ms,
+# defaults to 1000ms. (Since 8.1)
#
# @vcpu-dirty-limit: Dirtyrate limit (MB/s) during live migration.
-# Defaults to 1. (Since 8.1)
+# Defaults to 1. (Since 8.1)
#
# Features:
#
-# @unstable: Members @x-checkpoint-delay and @x-vcpu-dirty-limit-period
-# are experimental.
+# @unstable: Members @x-checkpoint-delay and
+# @x-vcpu-dirty-limit-period are experimental.
#
# Since: 2.4
##
--
2.40.1
next prev parent reply other threads:[~2023-06-22 19:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-22 19:50 [PATCH v2 0/5] Migration deprecated parts Juan Quintela
2023-06-22 19:50 ` Juan Quintela [this message]
2023-06-27 16:20 ` [PATCH v2 1/5] migration: Use proper indentation for migration.json Peter Xu
2023-06-22 19:50 ` [PATCH v2 2/5] migration: migrate 'inc' command option is deprecated Juan Quintela
2023-07-06 8:43 ` Thomas Huth
2023-06-22 19:50 ` [PATCH v2 3/5] migration: migrate 'blk' " Juan Quintela
2023-07-06 8:49 ` Thomas Huth
2023-06-22 19:50 ` [PATCH v2 4/5] migration: Deprecate block migration Juan Quintela
2023-06-22 19:50 ` [PATCH v2 5/5] migration: Deprecate old compression method Juan Quintela
2023-06-27 16:21 ` Peter Xu
2023-07-07 7:32 ` [PATCH v2 0/5] Migration deprecated parts Markus Armbruster
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=20230622195019.4396-2-quintela@redhat.com \
--to=quintela@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=fam@euphon.net \
--cc=leobras@redhat.com \
--cc=libvir-list@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@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).