From: peterx@redhat.com
To: qemu-devel@nongnu.org, Peter Maydell <peter.maydell@linaro.org>
Cc: peterx@redhat.com, "Fabiano Rosas" <farosas@suse.de>,
"Yong Huang" <yong.huang@smartx.com>,
"Cédric Le Goater" <clg@redhat.com>
Subject: [PULL 16/20] docs/migration: Split "dirty limit"
Date: Tue, 16 Jan 2024 11:19:43 +0800 [thread overview]
Message-ID: <20240116031947.69017-17-peterx@redhat.com> (raw)
In-Reply-To: <20240116031947.69017-1-peterx@redhat.com>
From: Peter Xu <peterx@redhat.com>
Split that into a separate file, put under "features".
Cc: Yong Huang <yong.huang@smartx.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/r/20240109064628.595453-8-peterx@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
---
docs/devel/migration/dirty-limit.rst | 71 ++++++++++++++++++++++++++++
docs/devel/migration/features.rst | 1 +
docs/devel/migration/main.rst | 71 ----------------------------
3 files changed, 72 insertions(+), 71 deletions(-)
create mode 100644 docs/devel/migration/dirty-limit.rst
diff --git a/docs/devel/migration/dirty-limit.rst b/docs/devel/migration/dirty-limit.rst
new file mode 100644
index 0000000000..8f32329d5f
--- /dev/null
+++ b/docs/devel/migration/dirty-limit.rst
@@ -0,0 +1,71 @@
+Dirty limit
+===========
+
+The dirty limit, short for dirty page rate upper limit, is a new capability
+introduced in the 8.1 QEMU release that uses a new algorithm based on the KVM
+dirty ring to throttle down the guest during live migration.
+
+The algorithm framework is as follows:
+
+::
+
+ ------------------------------------------------------------------------------
+ main --------------> throttle thread ------------> PREPARE(1) <--------
+ thread \ | |
+ \ | |
+ \ V |
+ -\ CALCULATE(2) |
+ \ | |
+ \ | |
+ \ V |
+ \ SET PENALTY(3) -----
+ -\ |
+ \ |
+ \ V
+ -> virtual CPU thread -------> ACCEPT PENALTY(4)
+ ------------------------------------------------------------------------------
+
+When the qmp command qmp_set_vcpu_dirty_limit is called for the first time,
+the QEMU main thread starts the throttle thread. The throttle thread, once
+launched, executes the loop, which consists of three steps:
+
+ - PREPARE (1)
+
+ The entire work of PREPARE (1) is preparation for the second stage,
+ CALCULATE(2), as the name implies. It involves preparing the dirty
+ page rate value and the corresponding upper limit of the VM:
+ The dirty page rate is calculated via the KVM dirty ring mechanism,
+ which tells QEMU how many dirty pages a virtual CPU has had since the
+ last KVM_EXIT_DIRTY_RING_FULL exception; The dirty page rate upper
+ limit is specified by caller, therefore fetch it directly.
+
+ - CALCULATE (2)
+
+ Calculate a suitable sleep period for each virtual CPU, which will be
+ used to determine the penalty for the target virtual CPU. The
+ computation must be done carefully in order to reduce the dirty page
+ rate progressively down to the upper limit without oscillation. To
+ achieve this, two strategies are provided: the first is to add or
+ subtract sleep time based on the ratio of the current dirty page rate
+ to the limit, which is used when the current dirty page rate is far
+ from the limit; the second is to add or subtract a fixed time when
+ the current dirty page rate is close to the limit.
+
+ - SET PENALTY (3)
+
+ Set the sleep time for each virtual CPU that should be penalized based
+ on the results of the calculation supplied by step CALCULATE (2).
+
+After completing the three above stages, the throttle thread loops back
+to step PREPARE (1) until the dirty limit is reached.
+
+On the other hand, each virtual CPU thread reads the sleep duration and
+sleeps in the path of the KVM_EXIT_DIRTY_RING_FULL exception handler, that
+is ACCEPT PENALTY (4). Virtual CPUs tied with writing processes will
+obviously exit to the path and get penalized, whereas virtual CPUs involved
+with read processes will not.
+
+In summary, thanks to the KVM dirty ring technology, the dirty limit
+algorithm will restrict virtual CPUs as needed to keep their dirty page
+rate inside the limit. This leads to more steady reading performance during
+live migration and can aid in improving large guest responsiveness.
diff --git a/docs/devel/migration/features.rst b/docs/devel/migration/features.rst
index 0054e0c900..e257d0d100 100644
--- a/docs/devel/migration/features.rst
+++ b/docs/devel/migration/features.rst
@@ -7,3 +7,4 @@ Migration has plenty of features to support different use cases.
:maxdepth: 2
postcopy
+ dirty-limit
diff --git a/docs/devel/migration/main.rst b/docs/devel/migration/main.rst
index 051ea43f0e..00b9c3d32f 100644
--- a/docs/devel/migration/main.rst
+++ b/docs/devel/migration/main.rst
@@ -573,74 +573,3 @@ path.
Return path - opened by main thread, written by main thread AND postcopy
thread (protected by rp_mutex)
-Dirty limit
-=====================
-The dirty limit, short for dirty page rate upper limit, is a new capability
-introduced in the 8.1 QEMU release that uses a new algorithm based on the KVM
-dirty ring to throttle down the guest during live migration.
-
-The algorithm framework is as follows:
-
-::
-
- ------------------------------------------------------------------------------
- main --------------> throttle thread ------------> PREPARE(1) <--------
- thread \ | |
- \ | |
- \ V |
- -\ CALCULATE(2) |
- \ | |
- \ | |
- \ V |
- \ SET PENALTY(3) -----
- -\ |
- \ |
- \ V
- -> virtual CPU thread -------> ACCEPT PENALTY(4)
- ------------------------------------------------------------------------------
-
-When the qmp command qmp_set_vcpu_dirty_limit is called for the first time,
-the QEMU main thread starts the throttle thread. The throttle thread, once
-launched, executes the loop, which consists of three steps:
-
- - PREPARE (1)
-
- The entire work of PREPARE (1) is preparation for the second stage,
- CALCULATE(2), as the name implies. It involves preparing the dirty
- page rate value and the corresponding upper limit of the VM:
- The dirty page rate is calculated via the KVM dirty ring mechanism,
- which tells QEMU how many dirty pages a virtual CPU has had since the
- last KVM_EXIT_DIRTY_RING_FULL exception; The dirty page rate upper
- limit is specified by caller, therefore fetch it directly.
-
- - CALCULATE (2)
-
- Calculate a suitable sleep period for each virtual CPU, which will be
- used to determine the penalty for the target virtual CPU. The
- computation must be done carefully in order to reduce the dirty page
- rate progressively down to the upper limit without oscillation. To
- achieve this, two strategies are provided: the first is to add or
- subtract sleep time based on the ratio of the current dirty page rate
- to the limit, which is used when the current dirty page rate is far
- from the limit; the second is to add or subtract a fixed time when
- the current dirty page rate is close to the limit.
-
- - SET PENALTY (3)
-
- Set the sleep time for each virtual CPU that should be penalized based
- on the results of the calculation supplied by step CALCULATE (2).
-
-After completing the three above stages, the throttle thread loops back
-to step PREPARE (1) until the dirty limit is reached.
-
-On the other hand, each virtual CPU thread reads the sleep duration and
-sleeps in the path of the KVM_EXIT_DIRTY_RING_FULL exception handler, that
-is ACCEPT PENALTY (4). Virtual CPUs tied with writing processes will
-obviously exit to the path and get penalized, whereas virtual CPUs involved
-with read processes will not.
-
-In summary, thanks to the KVM dirty ring technology, the dirty limit
-algorithm will restrict virtual CPUs as needed to keep their dirty page
-rate inside the limit. This leads to more steady reading performance during
-live migration and can aid in improving large guest responsiveness.
-
--
2.43.0
next prev parent reply other threads:[~2024-01-16 3:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-16 3:19 [PULL 00/20] Migration 20240116 patches peterx
2024-01-16 3:19 ` [PULL 01/20] migration: Simplify initial conditionals in migration for better readability peterx
2024-01-16 3:19 ` [PULL 02/20] migration/multifd: Remove MultiFDPages_t::packet_num peterx
2024-01-16 3:19 ` [PULL 03/20] migration/multifd: Remove QEMUFile from where it is not needed peterx
2024-01-16 3:19 ` [PULL 04/20] migration/multifd: Change multifd_pages_init argument peterx
2024-01-16 3:19 ` [PULL 05/20] migration: Report error in incoming migration peterx
2024-01-16 3:19 ` [PULL 06/20] tests/qtest/migration: Print migration incoming errors peterx
2024-01-16 3:19 ` [PULL 07/20] tests/qtest/migration: Add a wrapper to print test names peterx
2024-01-16 3:19 ` [PULL 08/20] tests/qtest/migration: Use the new migration_test_add peterx
2024-01-16 3:19 ` [PULL 09/20] tests/qtest: Re-enable multifd cancel test peterx
2024-01-16 3:19 ` [PULL 10/20] docs/migration: Create migration/ directory peterx
2024-01-16 3:19 ` [PULL 11/20] docs/migration: Create index page peterx
2024-01-16 3:19 ` [PULL 12/20] docs/migration: Convert virtio.txt into rST peterx
2024-01-16 3:19 ` [PULL 13/20] docs/migration: Split "Backwards compatibility" separately peterx
2024-01-16 3:19 ` [PULL 14/20] docs/migration: Split "Debugging" and "Firmware" peterx
2024-01-16 3:19 ` [PULL 15/20] docs/migration: Split "Postcopy" peterx
2024-01-16 3:19 ` peterx [this message]
2024-01-16 3:19 ` [PULL 17/20] docs/migration: Organize "Postcopy" page peterx
2024-01-16 3:19 ` [PULL 18/20] docs/migration: Further move vfio to be feature of migration peterx
2024-01-16 3:19 ` [PULL 19/20] docs/migration: Further move virtio " peterx
2024-01-16 3:19 ` [PULL 20/20] migration/rdma: define htonll/ntohll only if not predefined peterx
2024-01-16 16:33 ` [PULL 00/20] Migration 20240116 patches Peter Maydell
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=20240116031947.69017-17-peterx@redhat.com \
--to=peterx@redhat.com \
--cc=clg@redhat.com \
--cc=farosas@suse.de \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=yong.huang@smartx.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).