qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH RESEND v3 04/10] qapi/migration: Introduce x-vcpu-dirty-limit


From: Markus Armbruster
Subject: Re: [PATCH RESEND v3 04/10] qapi/migration: Introduce x-vcpu-dirty-limit-period parameter
Date: Wed, 11 Jan 2023 14:55:38 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

huangy81@chinatelecom.cn writes:

> From: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>
>
> Introduce "x-vcpu-dirty-limit-period" migration experimental
> parameter, which is in the range of 1 to 1000ms and used to
> make dirtyrate calculation period configurable.
>
> Currently with the "x-vcpu-dirty-limit-period" varies, the
> total time of live migration changes, test results show the
> optimal value of "x-vcpu-dirty-limit-period" ranges from
> 500ms to 1000 ms. "x-vcpu-dirty-limit-period" should be made
> stable once it proves best value can not be determined with
> developer's experiments.

I'm not a native speaker, but let me try to polish your prose anyway:

  The value of "x-vcpu-dirty-limit-period" affects how long live migration
  takes.  In my testing, the optimal value of "x-vcpu-dirty-limit-period"
  ranges from 500ms to 1000 ms.  If we can find a single value that is
  good enough for all use cases that matter, "x-vcpu-dirty-limit-period"
  can go away.  Else, "x-vcpu-dirty-limit-period" should be made stable.

Does this capture your intent?

> Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn>

[...]

> diff --git a/qapi/migration.json b/qapi/migration.json
> index 88ecf86..c428bcd 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -776,8 +776,13 @@
>  #                        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 7.3)

8.0, not 7.3, unless we change our versioning habits.  More of the same
below and later in this series; I'm not flagging it again.

> +#
>  # Features:
> -# @unstable: Member @x-checkpoint-delay is experimental.
> +# @unstable: Members @x-checkpoint-delay and @x-vcpu-dirty-limit-period
> +#            are experimental.
>  #
>  # Since: 2.4
>  ##

[...]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]