From: Fabiano Rosas <farosas@suse.de>
To: Hyman Huang <yong.huang@smartx.com>, qemu-devel@nongnu.org
Cc: Juan Quintela <quintela@redhat.com>, Peter Xu <peterx@redhat.com>,
Leonardo Bras <leobras@redhat.com>,
Thomas Huth <thuth@redhat.com>,
Laurent Vivier <lvivier@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Hyman Huang <yong.huang@smartx.com>
Subject: Re: [PATCH 6/6] docs/migration: Add the dirty limit section
Date: Thu, 19 Oct 2023 16:57:06 -0300 [thread overview]
Message-ID: <87ttqm5qst.fsf@suse.de> (raw)
In-Reply-To: <59985366f38053caac40c14d86b2a50bead944f6.1697502089.git.yong.huang@smartx.com>
Hyman Huang <yong.huang@smartx.com> writes:
> The dirty limit feature has been introduced since the 8.1
> QEMU release but has not reflected in the document, add a
> section for that.
>
> Signed-off-by: Hyman Huang <yong.huang@smartx.com>
> ---
> docs/devel/migration.rst | 71 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 71 insertions(+)
>
> diff --git a/docs/devel/migration.rst b/docs/devel/migration.rst
> index c3e1400c0c..1cbec22e2a 100644
> --- a/docs/devel/migration.rst
> +++ b/docs/devel/migration.rst
> @@ -588,6 +588,77 @@ 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 prepared for the second stage,
s/prepare/preparation/ might be more appropriate
> + 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_RULL exception; The dirty page rate upper
s/RULL/FULL
> + 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
There's a non-breaking space artifact between 'the' and 'dirty'
> + 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_RULL exception handler, that
s/RULL/FULL
> +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.
> +
> Postcopy
> ========
prev parent reply other threads:[~2023-10-19 19:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-17 11:36 [PATCH 0/6] dirtylimit: miscellaneous patches Hyman Huang
2023-10-17 11:36 ` [PATCH 1/6] system/dirtylimit: Fix a race situation Hyman Huang
2023-10-19 19:33 ` Fabiano Rosas
2023-10-17 11:36 ` [PATCH 2/6] system/dirtylimit: Drop the reduplicative check Hyman Huang
2023-10-19 19:36 ` Fabiano Rosas
2023-10-17 11:36 ` [PATCH 3/6] tests: Add migration dirty-limit capability test Hyman Huang
2023-10-19 20:01 ` Fabiano Rosas
2023-10-17 11:36 ` [PATCH 4/6] tests/migration: Introduce dirty-ring-size option into guestperf Hyman Huang
2023-10-17 11:36 ` [PATCH 5/6] tests/migration: Introduce dirty-limit " Hyman Huang
2023-10-17 11:36 ` [PATCH 6/6] docs/migration: Add the dirty limit section Hyman Huang
2023-10-19 19:57 ` Fabiano Rosas [this message]
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=87ttqm5qst.fsf@suse.de \
--to=farosas@suse.de \
--cc=leobras@redhat.com \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=thuth@redhat.com \
--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 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.