~hyman <hy...@git.sr.ht> writes:
> From: Hyman Huang(黄勇) <yong.hu...@smartx.com>
>
> 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.
dirty rate
>
> Currently with the "x-vcpu-dirty-limit-period" varies, the
Currently, as the
> total time of live migration changes, test results show the
Suggest period instead of comma.
> 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.
>
> Signed-off-by: Hyman Huang(黄勇) <yong.hu...@smartx.com>
> Reviewed-by: Markus Armbruster <arm...@redhat.com>
> Reviewed-by: Juan Quintela <quint...@redhat.com>
[...]
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -789,9 +789,14 @@
> # 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)
Two spaces after sentence-ending punctuation, please:
# @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)
> +#
> # Features:
> #
> -# @unstable: Member @x-checkpoint-delay is experimental.
> +# @unstable: Members @x-checkpoint-delay and
> +# @x-vcpu-dirty-limit-period are experimental.
> #
> # Since: 2.4
> ##
> @@ -809,8 +814,10 @@
> 'multifd-channels',
> 'xbzrle-cache-size', 'max-postcopy-bandwidth',
> 'max-cpu-throttle', 'multifd-compression',
> - 'multifd-zlib-level' ,'multifd-zstd-level',
> - 'block-bitmap-mapping' ] }
> + 'multifd-zlib-level', 'multifd-zstd-level',
> + 'block-bitmap-mapping',
> + { 'name': 'x-vcpu-dirty-limit-period',
> + 'features': ['unstable'] } ] }
>
> ##
> # @MigrateSetParameters:
> @@ -945,9 +952,14 @@
> # 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)
Likewise.
> +#
> # Features:
> #
> -# @unstable: Member @x-checkpoint-delay is experimental.
> +# @unstable: Members @x-checkpoint-delay and
> +# @x-vcpu-dirty-limit-period are experimental.
> #
> # TODO: either fuse back into MigrationParameters, or make
> # MigrationParameters members mandatory
> @@ -982,7 +994,9 @@
> '*multifd-compression': 'MultiFDCompression',
> '*multifd-zlib-level': 'uint8',
> '*multifd-zstd-level': 'uint8',
> - '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ] } }
> + '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ],
> + '*x-vcpu-dirty-limit-period': { 'type': 'uint64',
> + 'features': [ 'unstable' ] } } }
>
> ##
> # @migrate-set-parameters:
> @@ -1137,9 +1151,14 @@
> # 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)
Likewise.
> +#
> # Features:
> #
> -# @unstable: Member @x-checkpoint-delay is experimental.
> +# @unstable: Members @x-checkpoint-delay and
> +# @x-vcpu-dirty-limit-period are experimental.
> #
> # Since: 2.4
> ##
> @@ -1171,7 +1190,9 @@
> '*multifd-compression': 'MultiFDCompression',
> '*multifd-zlib-level': 'uint8',
> '*multifd-zstd-level': 'uint8',
> - '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ] } }
> + '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ],
> + '*x-vcpu-dirty-limit-period': { 'type': 'uint64',
> + 'features': [ 'unstable' ] } } }
>
> ##
> # @query-migrate-parameters:
The issues I'm pointing out don't justfy yet another respin. But if you
need to respin the series for some other reason, plase take care of them.
